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AN  AUTOMATED  ANNOTATED  BIBLIOGRAPHY 
ON  THE  SPECIFICATION  OF  INFORMATION  SYSTEM  REQUIREMENTS 


Introduction  and  Overview 

This  is  the  final  report  under  contract  #N00167-76-M-8441  with  the  Naval 
Ship  Research  and  Development  Center,  entitled  "An  Automated  Annotated  Biblio- 
graphy on  the  Specification  of  Information  System  Requirements".  It  represents 
the  Initial  step  in  a continuing  effort  to  gather  bibliographic  information 
relating  to  a defined  research  area.  Each  bibliographic  entry  is  chosen  for  Its 
relevance  to  this  research  area  and  each  is  annotated  and  assigned  descriptors 
from  the  perspective  of  this  research  area. 

The  research  area  is  concerned  with  the  capturing  of  information  system 
requirements,  the  development  of  a language  for  expressing  information  system 
requirements,  and  the  use  of  the  information  system  requirements  specification 
for  file  design  and  application  system  design  procedures.  The  defined  research 
area  is  viewed  primarily  from  the  perspective  of  database  technology  and  database 
management  systems. 

The  bibliography  for  this  report  contains  43  entries.  Each  entry  along 
with  a set  of  subject  descriptors  is  recorded  on  a SYSTEM  2000  database.  In 
addition,  an  annotation  was  prepared  manually  for  each  bibliographic  entry. 


Summary  of  Methodology 

1.  Search  out  and  identify  bibliographic  items  which  relate  to  the 
defined  research  area. 

2.  Develop  the  logical  schema  for  a bibliographic  entry,  develop  the 
formal  SYSTEM  2000  database  definition,  and  design  the  input  form 
for  data  capture. 

3.  For  each  item  reviewed  and  found  to  contain  some  useful  and  relevant 
material , 

a.  prepare  the  annotation  for  typing 


b.  assign  descriptors  and  descriptions 

c.  fill  out  the  input  form  for  the  automated  bibliographic  system 


4.  Obtain  the  output  to  prepare  a final  report  under  this  contract: 

a.  printout  of  bibliographic  entries  including  bibliographic 
citation,  descriptors,  and  incorporating  the  manually 
prepared  annotation,  ordered  by  identifier 

b.  index  by  author 

c.  tally  of  descriptor  terms  yielding  the  thesaurus 

d.  index  by  descriptor 

Summary  Schema  of  Bibliographic  Entry 

The  following  diagram  contains  the  essential  information  which  makes  up 
each  bibliographic  entry.  A full  definition  of  the  schema  is  contained  in 
Appendix  I. 


Figure  1.  Summary  Schema  of  Bibliographic  Entry 
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Criteria  for  Inclusion  of  a Bibliographic  Item 


"| 

■ 
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Bibliographic  items  were  selected  on  the  basis  of  their  relevance  to  the 
defined  research  area.  In  particular,  we  looked  for  articles  that  were  compre- 
hensive, broad,  contained  something  unique,  or  served  tp  advance  the  thinking 
in  some  aspect  of  the  subject.  In  some  cases,  items  were  included  simply 
because  most  would  agree  that  they  should  be  there. 

Formation  of  Thesaurus  of  Descriptors 

The  total  set  of  descriptors  used  in  preparing  this  automated  bibliography 
was  formed  by  a combination  of  bottom-up  and  top-down  development.  The  top-down 
development  stemmed  from  three  considerations: 

1.  Being  within  the  scope  of  the  research  area. 

2.  From  a database  management  perspective. 

3.  Toward  the  goal  of  developing  the  information  content  and  semantics 
of  an  information  system  requirements  specification  language. 

The  top-down  development  of  the  thesaurus  of  descriptors  was  influenced  sub- 
stantially by  initial  developments  under  the  second  research  contract  ( #N001 67- 
76-M-8476)  for  the  Naval  Ship  Research  and  Development  Center  entitled  "Developing 
a Data  Perspective  on  the  Specification  of  Information  System  Requirements". 

Some  of  the  work  for  the  second  contract  was  undertaken  concurrently  with  the 
work  under  this  contract.  The  top-down  formation  of  descriptors  begins  with 
data  structure,  patterns  of  processing,  and  behavioral  characteristics.  Further 
detail  can  be  found  in  Figure  2.  The  terms  and  concepts  reflected  in  Figure  2 
are  only  intended  to  be  illustrative.  They  are  not  complete.  In  so  far  as 
possible,  most  descriptors  relate  to  this  taxonomy,  but  not  all.  This  taxonomy 
of  terms  evolved  as  the  preparation  of  annotations  for  bibliographic  entries 
progressed. 


A 


Data  Structure 


data  items 
intrarecord  format 
•interrecord  structure 
semantic  constraints 
time  dimension 


Patterns  of  Processing 


operators- 


language 


on  data  items 

higher  level  database 
operators 


record-at-a-time  navigation 

file  level 

multifile 

functional 

parameter/application 


Behavioral  Characteristics 


of  data 
'of  processes 

^volume 

■volatility 

'timing 


Figure  2.  Initial  Top-Down  Formation  of  Descriptor  Thesaurus 
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The  thesaurus  of  descriptors  was  formed  in  a bottom-up  fashion  in  the  sense 
that  once  an  initial  taxonomy  of  terms  was  established,  we  then  used  whatever 
terms  seemed  most  appropriate  with  respect  to  each  individual  bibliographic  entry. 
No  attempt  was  made  to  obtain  completeness  or  absolute  consistency.  No  complete 
thesaurus  was  constructed  before  assigning  descriptors  to  bibliographic  entries. 

Preparing  the  Annotations 

For  each  bibliographic  entry,  an  annotation  was  prepared  according  to  the 
following  set  of  guidelines: 

1.  It  was  written  as  it  related  to  the  defined  research  area  and  the 
taxonomy  of  terminology  formed  as  described  in  the  previous  section. 

2.  A brief  summary  of  the  bibliographic  item. 

3.  To  highlight  the  unique  aspects  of  the  bibliographic  item. 

4.  To  highlight  the  better  or  fuller  treatments  of  a subject. 

5.  Highlight  the  omissions  and  unanswered  questions. 

6.  Provide  critique  and  evaluation. 

7.  Add  our  own  perceptions,  extensions,  or  generalizations. 

8.  Cast  the  annotation  in  our  own  terminology  rather  than  that  of  the 
article,  although  the  relationship  is  noted  whenever  it  is  not  obvious. 

Assigning  Descriptors 

Having  written  the  annotation  according  to  the  previous  guidelines,  it  was 
a fairly  straightforward  process  of  pulling  out  the  descriptors  for  each  biblio- 
graphic entry  --  they  were  derived  directly  from  the  annotation. 

Descriptions  of  the  Descriptors 

Associated  with  each  descriptor  of  each  bibliographic  entry  is  a description. 
The  description  is  a textual  field  intended  to  further  modify  or  explain  the 
descriptor  as  it  related  to  that  bibliographic  entry.  This  ''s  felt  to  be  a unique 

and  valuable  contribution  of  the  bibliography  developed  under  this  contract. 
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The  scheme  of  modifying  the  descriptor  aids  in  searching  the  bibliography. 

It  enables  a user  of  the  bibliography  to  increase  the  relevance  ratio.  That  is, 
having  retrieved  some  bibliographic  entries  based  upon  a set  of  descriptors,  the 
user  can  apply  a second  level  of  selection  by  reading  the  descriptions  associated 
with  each  descriptor  of  each  bibliographic  entry.  ; 

Input  and  Maintenance  of  Bibliographic  Entries 

The  bibliographic  citation  information  and  descriptors  with  associated 
descriptions  were  captured  on  an  input  data  form.  The  input  form  was  designed 
so  that  data  could  be  input  directly  to  SYSTEM  2000  in  the  form  it  was  captured. 

The  information  was  punched  onto  80-column  cards  before  being  entered  into  the 
system.  Once  the  database  was  established,  it  could  be  corrected  or  modified 
online  or  directly  on  the  cards.  We  chose  the  latter  and,  therefore,  would  re-create 
the  database  each  time  some  corrections  were  made  to  the  bibliographic  entries. 

This  presents  no  problem  for  a small  database  and  provides  convenient  backup  protec- 
tion. When  the  database  is  larger  it  is  possible  to  dump  the  database  to  tape 
for  backup. 

Output 

Four  major  output  reports  were  obtained  from  the  bibliographic  system. 

These  reports  are  contained  in  Appendix  2.  The  following  is  a brief  description 
of  each  report: 

1 . Bibliographic  Entries 

This  report  contains  a printout  of  all  the  information  in  the 
bibliographic  system.  Each  bibliographic  entry  is  printed  with  the 
title,  author (s),  source,  publication,  descriptors  and  descriptions, 
along  with  the  manually  prepared  annotation.  The  output  is  ordered 
according  to  bibliographic  entry  identifier.  Since  the  identifier 
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is  formed  from  a combination  of  year  published  and  author  name,  the  output 
is  first  ordered  by  year  and  then  ordered  by  author. 

2.  Author  Index 


| 


The  second  report  simply  contains  a printout  of  authors  and  for 
each  provides  the  one  or  more  bibliographic  entry  identifiers  related 
to  that  author. 

3.  Tally  of  Descriptors  --  Thesaurus 

SYSTEM  2000  provides  a unique  feature  of  being  able  to  tally  all 
the  unique  values  of  any  particular  data  item  within  the  database.  By 
doing  this  on  the  descriptor  data  item,  we  effectively  obtain  a printout 
of  the  thesaurus  used  in  the  bibliography.  This  does  not  represent  a 
controlled  thesaurus.  Some  cleanup  for  consistency  was  performed  on 
the  descriptors.  Additional  manipulation  and  improvement  of  the  thesaurus 
is  possible.  For  example,  we  could  add  cross-references  within  the  set 
of  descriptors  (including  both  "conditions  on  query",  "query  conditions",  say). 

4.  Descriptor  Index 

The  fourth  report  from  the  bibliography  consists  of  a printout  of 
each  descriptor  followed  by  the  relevant  citations  associated  with  that 
descriptor  and  for  each  citation  the  description  associated  with  that 
descriptor.  We  initially  attempted  to  print  each  descriptor  only  once, 
but  this  proved  to  be  impossible  using  the  PRINT  facility  of  SYSTEM  2000. 

Therefore,  the  descriptor  appears  printed  out  before  each  individual 
citation. 

Online  Availability  of  the  Bibliographic  Database 

The  bibliographic  database  prepared  under  this  contract  was  established  and 
is  maintained  under  SYSTEM  2000.  The  system  can  be  accessed  online  from  a remote 
terminal.  Since  the  bibliography  continues  to  grow  and  evolve,  readers  of  this 
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report  may  desire  to  access  the  latest  version  of  the  bibliography.  Appropriate 
arrangements  can  be  made  by  contacting  the  principal  investigator: 

Dr.  Gordon  C.  Everest 

Management  Information  Systems  Research  Center 
Graduate  School  of  Business  Administration 
UNIVERSITY  OF  MINNESOTA 
Minneapolis,  MN  55455 
Phone  (612)  373-5601 


Conclusion  and  Observations 

Having  prepared  an  initial  taxonomy  of  concepts  and  terminology  relating 
to  our  particular  perspective  on  the  research  area,  the  writing  of  annotations 
and  assigning  of  descriptor  terms  proved  to  be  an  extremely  fruitful  and  enlighting 
exercise.  It  provided  substantial  insight  into  the  relationship  between  what 
other  authors  are  saying  about  this  subject  area  and  the  way  we  have  been  thinking 
of  this  subject  research  area.  In  relation  to  the  next  and  following  contracts 
in  this  area,  this  bibliography  will  provide  substantial  input  and  support.  It 
will  be  a useful  continuing  process  in  support  of  future  contract  activities. 

One  significant  observation  is  the  distinction  between  what  the  user  must 
specify  regarding  his  information  system  requirements  and  what  is  typically  re- 
quired as  input  for  a database  management  system  or  file  design  procedure  or 
application  system  design  procedure.  Some  of  the  required  input  information  is 
exogenous  and  basic  to  the  way  the  user  thinks;  other  information  is  more  properly 
derived  from  what  the  user  would  specify.  For  example,  most  systems  required  the 
user  to  declare  which  data  items  in  a data  definition  should  be  indexed  for  more 
rapid  retrieval.  This  decision  really  rests  on  or  is  derived  from  information 
about  the  different  types  of  queries  against  the  database,  their  relative  frequency, 
and  their  required  response  rate.  This  points  up  the  importance  of  gathering 
behavioral  information  with  respect  to  the  data  structure  and  the  patterns  of 
processing  against  the  database.  However,  we  noticed  a distinct  lack  of  materials 
that  related  to  the  specification  of  behavioral  characteristics. 
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Bibliographic  Entry  Data  Definition 

In  SYSTEM  2000  all  data  items  are  considered  optional  by  the  system.  This 
permitted  substantial  flexibility  for  we  could  define  a set  of  data  items  and 
then  use  only  those  that  are  required  for  a particular  bibliographic  entry. 

This  can  be  seen  particularly  in  the  definition  of  serial  title  and  monograph 
title  along  with  the  title  of  the  bibliographic  item. 

With  all  data  items  optional  only  those  item  values  which  exist  will  be 
printed  out  along  with  the  data  item  name.  The  bibliographic  schema  was  estab- 
lished to  take  best  advantage  of  the  system.  For  example,  if  the  title  of  a 
conference  proceedings  is  recorded  in  SERIAL  TITLE  and  the  editor  is  recorded  in 
EDITOR,  but  nothing  is  recorded  in  MONOGRAPH  TITLE,  the  printout  will  show  only 
SERIAL  TITLE  and  EDITOR.  There  is  no  ambiguity  concerning  what  the  editor 
applies  to. 

The  formation  of  the  bibliographic  entry  identifier  from  the  year  of  publi- 
cation and  the  author's  last  name  permitted  us  to  couple  the  identifier  with  the 
title  and  obtain  a high  level  of  information  in  these  two  data  items.  This  two 
field  identification  is  used  in  the  Descriptor  Index  and  on  the  annotations. 


BIBLIOGRAPHIC  ENTRY  SCHEMA 
GRAPHICAL  REPRESENTATION 


Bibliographic) 
Entry 


IDentifier  (YYAUTHOR) 


1 

~ 

_ 1 

AUTHOR 

TITLE 

SERIAL  TITLE 
SERIAL  NUMBER 
MONOGRAPH  TITLE  > 
MONOGRAPH  NUMBER 
EDITOR  > 

PUBLISHER 
PUBLISHER  LOCATION 
DATE 
PAGES 


Used  as  needed  if 
title  is  part  of 
larger  work. 


i 

““ 

f 

DESCRIPTOR 

__ 

— 

— 

DESCRIPTION 

— 

- 

ANNOTATION  (not  mechanized) 


BIBLIOGRAPHY  SCHEMA 


DATA  ITEM  DESCRIPTIONS 

ID  YYAUTHOR:  Each  article  is  assigned  a unique  identifier  consisting  of  two 

subfields.  The  first  subfield  is  made  up  of  the  last  two  digits  of  the  year 
the  article  was  published;  the  second  subfield  contains  the  last  name  of  the 
author(s).  If  there  are  two  or  three  authors,  the  second  subfield  includes  the 
last  name  of  each  author  linked  by  a plus  sign  (first  + second  + third).  If 
there  are  several  authors,  only  the  first  author  is  used  in  the  ID.  If  the 
bibliography  includes  more  than  one  item  for  the  same  author  in  the  same  year, 
a digit  is  added  after  his  name  (e.g.,  75SMITH2)  to  ensure  uniqueness. 

AUTHOR  is  a repeating  group  of  two  data  items,  AUTHOR  NAME  and  FIRST  NAME,  with 
up  to  three  instances. 

AUTHOR  NAME:  contains  only  the  last  name  of  the  author  with  no  extra  punctua- 

tion. If  there  is  a corporate  author,  the  last  name  is  the  name  of  the  corpor- 
ation. When  reviewing  specific  Database  Management  Systems,  the  developer  is 
listed  as  the  author. 

FIRST  NAME:  contains  the  first  name  of  the  author  and  any  additional  descriptive 

information  about  the  author.  This  data  item  may  contain  any  combination  of  the 
following: 

a.  author's  first  name  and/or  initials 

b.  additional  name  appendages  (JR.,  Ill) 

c.  author  role  (EDITOR,  COMPILER) 

d.  multiple  author  designation  (ET  AL.) 

e.  corporate  author  designations  (INC.,  CO.,  CORP.,  SA,  AG) 


it 
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TITLE:  The  primary  title  of  the  bibliographic  entry  is  always  recorded  in  the 

TITLE  field,  whether  it  is  the  title  of  an  article,  chapter,  or  paper  in  a larger 
work  (such  as  a periodical,  journal,  book,  or  conference  proceedings)  or  it  is 
the  title  of  a complete  work  published  as  a self-contained  volume  (book,  manual, 
report,  thesis,  research  monograph,  or  working  paper).  If  the  bibliographic 
entry  is  part  of  a larger  work,  its  title  is  enclosed  in  quotation  marks,  and  the 
title  of  the  larger  work  is  given  under  SERIAL  TITLE  or  MONOGRAPH  TITLE.  If  the 
proceedings  of  a conference  is  published  as  an  issue  of  a serial,  the  information 
is  in  both  SERIAL  TITLE  and  MONOGRAPH  TITLE. 

SERIAL  TITLE:  contains  the  title  of  the  larger  work  in  which  the  bibliographic 

entry  TITLE  appeared,  but  only  when  the  larger  work  is  published  on  a repeating 
basis  with  the  same  title  (e.g.,  journal,  periodical,  conference  proceedings). 
Below  are  examples  of  several  of  the  more  frequently  referenced  conferences: 

PROCEEDINGS  ACM  NATIONAL  CONFERENCE 
PROCEEDINGS  NATIONAL  COMPUTER  CONFERENCE 
PROCEEDINGS  ACM-SIGMOD  WORKSHOP 

SERIAL  NUMBER:  If  the  source  is  a serial,  this  will  identify  the  volume  and 

number.  The  format  is  "volume: number."  If  there  is  only  a volume  designation, 
the  format  "VOLUME  45"  is  used.  The  number  of  issue  may  be  either  an  integer 
(15:6)  or  a season  (15: FALL ) . The  actual  date  of  the  serial  is  given  below 
under  year  and  date.  In  general,  the  SERIAL  NUMBER  field  contains  any  necessary 
modifiers  to  the  SERIAL  TITLE. 

MONOGRAPH  TITLE:  If  the  bibliographic  entry  is  part  of  a larger  self-contained 

volume,  this  field  contains  the  title  of  the  larger  work. 


MONOGRAPH  NUMBER:  This  field  provides  additional  information  which  modifies  or 


completes  the  MONOGRAPH  TITLE.  This  field  contains  such  information  as  edition 
number  (if  greater  than  the  first),  NTIS  number,  Government  report  number,  or 
number  in  a working  paper  series. 

EDITOR:  Identifies  the  editor  of  either  a SERIAL  TITLE  or  a MONOGRAPH  TITLE. 

It  is  shown  in  the  form  "LAST  NAME,  FIRST  NAME." 

PUBLISHER:  Identifies  the  name  of  the  publisher  who  produced  the  self-contained 

volume  of  the  bibliographic  entry  TITLE  or  the  SERIAL  or  MONOGRAPH  in  which  it 
appeared.  For  joint  publishers,  only  the  primary  publisher  is  recorded.  This 
field  is  often  not  necessary  for  well  known  SERIAL  TITLES. 

PUBLISHER  LOCATION:  City  (and  state)  of  the  publisher,  that  is,  the  source  for 

obtaining  the  TITLE.  For  proceedings  it  is  the  location  of  the  publisher,  not 

\ 

the  conference. 

YEAR:  Contains  the  year  of  publication  (or  production  if  unpublished  item). 

This  field  always  contains  a value  as  a four  digit  number. 

DATE:  This  field  is  used  when  more  information  than  year  is  relevant  for  the 
publication  date.  It  may  contain  year  month  day  as  YYYY/MM/DD  or  year  and 
season. 


PAGES : The  pages  on  which  the  article  or  chapter  appears  if  it  is  part  of  a 
larger  work  (format  NN-MM)  or  the  total  number  of  pages  if  the  bibliographic 
entry  is  a self-contained  volume  (format  NNN). 


«& ■ ^ ***'•'' 


SUBJECTS:  A repeating  group  containing  a DESCRIPTOR  and  associated  DESCRIPTION 


data  items. 

DESCRIPTOR:  A subject  term  or  phrase  which  describes  the  bibliographic  entry 
as  it  relates  to  an  interest  in  the  research  area.  Every  attempt  was  made  to 
use  descriptors  in  a way  consistent  with  the  research  area  and  consistent  across 
all  bibliographic  entries.  A listing  of  all  descriptors  used  so  far  is  attached. 
This  list  is  not  intended  to  be  exhaustive  of  the  research  area;  it  was  built  up 
by  tallying  the  terms  used  with  each  entry.  DESCRIPTORS  were  not  assigned  to 
be  descriptive  of  the  entire  bibliographic  entry;  but  only  to  capture  the  unique 
aspects  of  the  entry  as  it  relates  to  the  research  area. 


t 

j 

I 

i 

i 


DESCRIPTION:  A text  field  to  accompany  each  DESCRIPTOR  for  each  bibliographic 
entry.  It  is  used  to  indicate  such  things  as: 

- the  viewpoint  taken  on  the  DESCRIPTOR 

- more  detail  from  the  entry  as  it  relates  to  the  DESCRIPTOR 

- the  page  numbers  in  the  entry  to  which  the  DESCRIPTOR  applies 
(if  the  entry  is  a large  work) 

The  description  field  is  not  always  used. 
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BIBLIOGRAPHY  SCHEMA 

DATA  ITEM  AND  REPEATING  GROUP  DEFINITION  TABLE 


ITEM  NAME 

KEYED 

FORMAT  TYPE 

EXISTENCE 

SAMPLE  VALUES 

ID  YY AUTHOR 

KEY 

YYAAAA. ..[n] 

MANDATORY,  UNIQUE 

68SMITH 
75JONES1 
76SMITH  + JONES 

AUTHOR  (RG~up  to 

three 

instances) 

AUTHOR  NAME 

KEY 

ALPHA  ONLY 
(no  punctuation) 

MANDATORY 
(one) . 

EVEREST 

(Last  name  only) 

FIRST  NAME 

no 

Char  String 

GORDON 
G.C.,  JR. 
EDITOR 

INC. 

ET  AL. 
CORP 

TITLE 

KEY 

text 

MANDATORY 

(in  quotes  if  part 
of  larger  work.) 

SERIAL  TITLE 

no 

text 

SERIAL  NUMBER 

no 

Char  String 

15:6 
15: FALL 

MONOGRAPH  TITLE 

no 

text 

MONOGRAPH  NUMBER 

no 

Char  String 

THIRD  EDITION 
AD  942  371 

EDITOR 

no 

Char  String 

JONES,  G.C 

. JR 

PUBLISHER 

KEY 

Alpha 

MCGRAW-HILL 

PUBLISHER  LOCATION 

no 

Char  String 

ST  PAUL,  MN 

YEAR 

KEY 

NNNN 

MANDATORY 

1975 

DATE 

no 

Alpha/numeric 

only  if  more 
than  year 

1975/10 
1976  FALL 

PAGES 

no 

NN 

NN-MM 

395  (total  pages) 
22-35  (from-to) 

SUBJECTS  (RG) 

DESCRIPTOR 

KEY 

alpha 

MANDATORY 
(one  instance) 

DESCRIPTOR 

no 

text 

(one  for  each  de- 
scriptor; optional ) . 

ANNOTATION 

. - 

text 

MANDATORY 

(not  MECHANIZED). 

1* 

IU  YYALTPO- 

( Ktr  uaWL 

) : 

A 

?« 

title 

l K 6 Y i\Ahr. ) S 

'j 

4* 

SERIAL  1ITLE 

( isOis  -r.fc  Y 

N A P E 

) 1 

J 

4 1* 

SERIAL  IsLPfcF  

( Ol\  — is  6 Y 

1 i A |“  t 

) 1 

i 

5* 

P'OtCGRAPP  1 I TLt  

( MjK  -tvt  Y 

IvAp  t 

) : 

A 

5V* 

MCNCGRARF  MRiREh-  — 

( f.OlS-rst  Y 

i(Al»li 

) : 

•-hs» 

5?« 

ElITCK 

( Mils  -Kt  Y 

Ka  t-  t 

) : 

j J 

e« 

purl  isi-ee 

1 is  t Y l.ttME 

i : 

61* 

POfcllSREh  LOCATION- 

( isGl'  -1st  Y 

IVAPt 

) : 

£Vl 

?« 

YE  AR  — 

( ply  im 

9(4) 

) : 

71* 

Date 

l nOIs-isEY 

ISAM- 

) ; 

1 

7?« 

pages 

l nuis-KE  Y 

IS  *'  P F 

) : 

>-  *■* 

e c « 

A i,  T P C H 

( i<i'  ) : 

8*  AUTHOR  NAPE- 

( IS  E Y NAME 

ll\ 

bO  ] 

i : 

6 1*  FIRST  MpE  — 

( lsOls-l\t  Y 

IS  A p t 

i IS 

d u 

9(1* 

SuRwECTS 

( *g  ) : 

9*  DESCRIPTOR  — 

l l\L  Y Is  AM 

i IS 

V)  ) 

i : 

91*  DESCRIPTION- 

i r ; • i n - tv  t y 

' , A P L 

iP 

90 

Naval  Ship  R&D  Center 
BIBLIOGRAPHY  INPUT  FORM 

ID  YYADTHOR:  1* 

TITLE:  2* 


SERIAL  TITLE 

4* 

★ 

SERIAL  NUMBER: 

41* 

★ 

MONOGRAPH  TITLE: 

5* 

* 

MONOGRAPH  NUMBER: 

51* 

* 

EDITOR: 

52* 

★ 

PUBLISHER: 

6* 

★ 

PUBLISHER  LOCATION: 

61* 

★ 

YEAR: 

7* 

★ 

DATE: 

71* 

* 

PAGES: 

72* 

★ 

AUTHOR  NAME: 

80*8* 

★ 

FIRST  NAME: 

81* 

★ 

AUTHOR  NAME: 

80*8* 

★ 

FIRST  NAME: 

81* 

it 

AUTHOR  NAME: 

80*8* 

* 

FIRST  NAME: 

81* 

★ 

DESCRIPTOR: 

90*9* 

* 

DESCRIPTION: 

91* 

★ 

DESCRIPTOR: 

90*9* 

★ 

DESCRIPTION: 

91* 

★ 

DESCRIPTOR: 

90*9* 

★ 

DESCRIPTION: 

91* 

*□ 

OVER 


197609 
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DESCRIPTOR: 

DESCRIPTION: 


DESCRIPTOR: 


90*9* 


DESCRIPTION: 


DESCRIPTOR: 


90*9* 


DESCRIPTION: 


DESCRIPTOR: 


90*9* 


DESCRIPTION: 


DESCRIPTOR: 


90*9* 


DESCRIPTION: 


DESCRIPTOR: 

DESCRIPTION: 


90*9* 


DESCRIPTOR: 

DESCRIPTION: 


90*9* 


DESCRIPTOR: 

DESCRIPTION: 


90*9* 


APPENDIX  II 


Output  Reports 

Table  of  Contents 


1. 

Tally  of  Descriptors 

--  Thesaurus 

2. 

Author  Index 

3. 

Descriptor  Index 

4. 

Bibliographic  Entries 

with  Annotations 

««««««»«« 


EIEpENT- 


CESCNlhTon  — 

!***««*■»** 


FREUuF.rsCY 


value 


TALLY  OF  DESCRIPTORS  “ THESAURUS 


AHSIhaCT  L>aTA  IYFE 

ACCESS  CONTROL 

ACCESS  CONTROL  RE  CN  Ah!  Sr',S 

ACCESS  P A T r 

ACCESS  HHlviLEL-hS 

A PPL ICaT ION  SYSTEM 

ATTR lbUTtS 

AUDIT 

AUDI  T Of' 

PaCNlP  aNU  hECLV E.Ry 

P A C N U P L'  A T A 

PaCKUP  STPaTLCY 

PEHAVIoPAL  CnAAACl f KiST iCS 

CUMFUUhl  DATA  sTPUCTCkc  OPtPATORS 

COPPHESSiON  OPERA  T OP 

CUNCu KhEnOY  UStH  COvlv  f’S 

CONCORKfc.nl  cumrcl 

CONCURRENT  PHCCESSE.  S 
CONCITICwS  (iN  a PKuCtaC 
CPF  AT  I « J in. 

CATA  CONSISTENCY  KuLtS 
DATA  DtP  AkI TICn 

CATA  DEPENDENT  ACCESS  UUnTpoL 

CATA  UEPlNI  FNT  UPUAIE 

CATA  UiCflUNAHY 

CATA  INTtUPlTY 

CATa  I TEN  LET  1M  f IO 

CATA  I I Ei-'  DERIVATION  POLES 

CATa  ITem  opEPaTCKS 

CATA  LOSS 

CATA  STPUCiOPE 

TATA  STRUCTURE  uEFI.mIIICN 

CATA  SlPUCTUPE  NIGUEL 

CATA  SIaOCTUPE  U p E P a 1 o p s 

CATAbASt  utSlOP 

DATABASE  DESIGN  FKOCElOPE 

CATaE"  AoE  Pi  A NACt  Mfc  NT  SYSTEN 

CATABASE  OPEPA I I OKS 

CATAbASt  UPtPAluRS 

CATAbASt  SYSTEN  OtSION  OhjECTIvLS 

CATE  SENSITIVE  FILE 

CEAILOCN 

TESIGN  UATmPASE 

rtsiGN  thaueofes 

CEVICt  INDEPENDENCE 

F NCC  UE/ DECODE 

ENCRYPTION 

EVOL vAblLlT  Y 

EXcEPTICk  CONE  1 I ION  ACTIONS 
EXCEPT  ION  CONDITION  PESPUN.SE  S 
EXCEPTION  CONDITIONS 
EXCEPTION  PROCESSING 

feature  list 

FILE  LtVEL  uEPivATIUP 
FLAT  FILL 
FLOW  UmTa 

F ORE  ATICn  a No  P P E SE  I'**  I a T ION 


jsagfi*  jm 
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1 FUNCTIONS 

] GRAPHICAL  OUlPoT 

1 P IFFARCHICAL  SELECTION  C^HtHlA 

1 PlGP  LEVtL  LANGUagF 

4 PlGP  LEVtL  MULTIFILE  LANGUAGE 

1 INDEX  litUMTIth 

1 II'JFEREKT  IAL  PElKltVAL 

3 INFCRMAT  ION  ALGEriKA 

1 INFCRMAT  iUio  RE*»U  I REI-ck  T a 

1 I NFC  HP  A T lUT  SYbTFM  MUUfcLLlr.G 

2 INFORMATION  SYSTEM  REUDIREmENIS  SPECIF ICA 1 ICnS 

1 INFORMATION  SYSTEM  Rt  uU  I *6  .MfcNTS  si  ATcMFNT  LANoOaijE 

1 INTERROGATION 

1 LOCKS  ON  OATA 

1 LOGICAL  rage  S12E 

1 OBJECTIVES 

3 FATTERNS  OF  PROCESSING 

1 fepformance  criteria 

2 FERFORmaNCE  MCnITORIKG 

2 FRF.MISt  aCTIuN 

3 PROCESS  OEKlNlIICiM 

l program  generation 

1 FSL 

1 GuERY  CCinOIT  1Ci\S 

1 GUFRY  RESPONSES 

2 GUFRY  TYKES 

1 F tCC  VERY 

1 RECCVERY  RROCEUOHtS 

7 REPCaT  definition 

2 REPORT  GENERATION 

1 FESTARI 

1 RETENTION 

1 RULES  OF  UFERENCt 

1 SECLRITY 

1 SECLRITY  «ON] TORINO 

4 SELECTION  CRIltRxA 

2 SEMANTIC  CONSTRAINTS 

l semantic  integrity 

i status  OaTa 

1 STRING  lltM  TYKt 

2 SURVtY  OF  OMS 

1 SYSTEM  DtVELORFtNl  PhASP.G 

1 TEXT  ITEM  TYPE 

1 TIME 

2 TIME  STAMPING 

1 T RALE OF  Fa 

3 TRANSACTION  DEFINITION 

2 TRANSACTION  PROCESSING 

1 TRANSACTION  VAoluAT  lO’N  ORUERIa 

1 trigger 

2 LPOATE 

3 LPOATE  PHOCESStS 

3 LSFRSCHfcMA 

1 VALIDATION 

ft  VAL IDATIUN  CRITERIA 

1 VALIDATIUN  PROCtSS 

2 VALloAlION  RLSfOnSk 


l 1 4 

LMGLE  VALUED 

213 

OCCURRENCES 
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AUTt-TK  NApv 

««« 

* ASTPAhAr 

* PLF  IFR 

* BUKROUGPS 
« CH/, WHE^I.  IN 

« CODASYl  SYSTEMS  CCi-<"  1 1 tea 
« COlL^EYEh 
« COp  SHaPF 

* COpPlTfcP  ASSCClAlLb 

« COMPUTER  CCpPORATIus  Of  mPC.*10a 

* COpPUVISCR 

<*  C Op  T POL  l-  A T A 
« COiv  « A Y 

* DA|.. A 

« OIjKSTM 

* E S a p A p 

* FOSTPN 

* GOOOENOLGP 

* GRIFFITpS 

« hammer 

* hamper 

* HOFFpAN 

* IBf 

« K AhN 
« KING 

* L E a V F Nl  w C R T F 

* L IkDGRl F a 

* LISKCV 
« LYr.CP 

« PAy*FLL 

* PClFCU 
« n* ir  sky 
« PORGaN. 

•NUfA^AKFR  ^ 

* GLUE 

* PETFPSON 
« POPFK 

* RKESSFR 

« RROGWAN  PKOCICTS 
« RANDALL 
« SAN^FT 

* SAvAM 

« SCHFUEHNANN 

« SEnkc 

* SHNEinF.R^AN 

* SKINNER 

* SNOGGS 

* SWt'NSOisi 
« Taggart 

« TE  IChRijF  a 

* TOMK 

* TSlChPlTZlS 
« UNIV/lC 

* O.S.  DNPARTnFNT  OF  UtNF.NSt 

* MOF 

« wtPF.P 

* RHJNFTON 

* mus 


I i ! Y Y An  I r.OH 


Vo  AS  I PAM  Al\ 
7<UiLt  ItH 


2. 


AUTHOR  INDEX 


7b  HUP  KUPoFS 

7St  SwaPaim  ♦ CM  A i' n t RL  l N 
7 l Col.  Aa  t L 

7 3KlM»  ♦ COLLPlYl  P 
7 3 CON  SnAPt. 

/SCOPPOlLP  A5S0ClATLb 

74CCPPUIF.P  OtlRPohAT  1 CH  CF  APtHlCA 

I loOPPOV ISOH 
7 ii  CD  C 

7 ICON  WAT  ♦ P A A *t  LL  ♦ POHGAS 
7<M'Ai\A  ♦ PHtSStn 
/ oL)  I JN  S I P a 

7sFb*APANj  ♦ CP«f  PFRLIim 

7JHJSTtM 

7 5 o U C 1 1 E iy  0 0 o H 

/hijPIFPiThb  ♦ «‘'Cf. 

7 AriAp  i-ltH 

7 S h A N 1 1 1 P ♦ PCLtoi; 

7 1 h 0 F F P A 
V 0 1 H I- 
7bKAPI\i 

/JMM."  ♦ COL  I ivt  T t a 
7 A L F A V L iv  to  0 H I P ♦ S A i“  P F T 
7 hL  IN  t N 
7 '♦  L I b N O ^ ♦ Z I L L t S 
b S L Y l\  C M 

7LCuN*aT  ♦ NAAwCLL  ♦ p 0 P G A N 
/ S M A iv  M t p ♦ C L 1 0 1 i 
7 *4  p 1 N !j  i\  Y 

7 I CON  wa  Y ♦ PAAwlLL  * a UP  0 Au 
7 ji\iON«riAKtP  ♦ S*tNSCN  ♦ < M 1 Im S 1 Uiv 
/AULLL 

7A3IVOOOA  ♦ Pl.iPtN  ♦ PtltPSOiv 
7aSni  GgS  ♦ Pr.PtiN  ♦ PfcltPSUu 
/dllAGA  ♦ PRtSSti' 

VAPHCOPAP  PRODUCTS 
7aPAi\UauL 

7‘*LcA^t.|Y*0Plh  ♦ S A M * fc.  I 
7 A S A Y A A|  i 

/ ASMNF.  iOEPPAN  ♦ SCPtOtPP  ANIV 
72SF.NKU 

7 A SnSfc  1 UE  PMttfM  ♦ SCMtOtPPftNN 
7Abl\  lIMlMtH 

7hSNL0O3  ♦ P n P t N + PtTtPSCN 

73l\iOi\ Ama^ep  ♦ SRtNSCi\  ♦ AhlNSlOrs 

/ a T Aco««T 

7cT  fe lOMPOt  w 

7 1 1 UN  1 K 

7s (SICppI  TZiS 

7SUM  v A L 

0 7t).b.  ouD 

7boPIPPiTPS  ♦ waiJE 

/ S w t P h K 

7 JNON  AhAKEP  ♦ bRf.NSCix  ♦ WHIN.STON 
7AL1SM/V  ♦ i I L L t S 
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3. 


DESCRIPTOR  INDEX 


ABSTRACT  LATA  TYPt 
74HAPPER 

<UATA  AhSTPaCTIONS  Fo*  iaTa  G«StS* 

DATA  sTRUTIHF  PloS  Ai LOwtD  OPERATORS 


abstract  i;ata  TYPt 

74LISKOV  ♦ / ILLFS 

jtPROGRANP  INC-  MTP  AHSlKACT  laTa  T Y P F S * 

LCB I CAL  CATA  Type  l«  STpOCTlPt  Cr».RACTtPI  Itu  hY  I hE  OPE 
RATIONS  AvAiLAdLt  ON  IT 


ACCESS  CCfTROl. 

74MINSKY  DLJi 

*CN  INTERACT  ICn  klTM  OaTa  PhSES* 

data  lepenufnt 


jfi 


ACCESS  COIKUI. 

7 1COCASYL 

FEATURE  ANALYSIS  UE  Ot.ur  hmL  i/EO  UmT,,  bAst  P a haOL  a lM  SYST 
EPS 

Privacy  locks  pY  uaIa  element  ui  lny  llvll)  ok  &y  Mjivc 
T ICN 

access  ccr  TNul 

76GPIFF1TPS  ♦ WALE 

t AN  AOThCP  I 7 A 7 ION  PE  CP1  AN  I SP  FC*  a RELATIONAL  Database  SYS 

TEN  * 

GRANTING  A N 0 REVGMhO  ACCcSS  I’m  i v i L t(.t  S . MjHPIiso  Nt ! *CR 
K OF  PR  I V 1 LE'.'lr.S  . 


ACCESS  CCMROL 
7 OCL'C 

PARS  III  REFERENCE  PANOAL 

PRIVACY  LEVELS 

ACCESS  CON  TROL 
75ESW aRAN  ♦ CPAPPENLIN 

^FUNCTIONAL  SPECIFICa  I LOUS  ON  A aOtSYSTE.M  E(h  OAIa  oASc  I 
NTfcOKITY* 

By  FUNCTION*  ESPECIALLY  Uh  Md  JNYJNG  vAlIUATIik  C>IINP 
i A 

ACCESS  CCnTROL 

7 0 IBP 

CIS  VERSION  i APE  L I C A f I < N Ufc SC* T p I i On 

FILE  aNl  ITEM  LEVLL.  HEP  StOONjlY  (,Ol  t S ATUCPtU  1 0 lb 
CP  1.  S E F PASSWORD 

ACCESS  CCn  TRUE 
7f ASTRAHAN 

aSYSTFP  Ri  PELaT  IOn/iL  APPPOaCP  To  lATAhaSE  P ANApEPtM  * 
USER  GRANTS  All  TOOl<  W A 1 I ON  FCP  nt«L*  O AN.OE  i INSERT*  Ot.L 
F.TE*  C R t A T E L INnS  Op  Vlt*S 

ACCESS  CC'-TRUL 
7 IMCiEFMaN 

#THF  FORPOl  »•  pY  MCbtl  FOi  ELENltlL  PRIVACY  aNO  ACCESS  COM 
POLS* 

USER  WRITTEN  AC  TmijH  ll>i  T 1 ON  ROUTINES  »hIOP  EAC.COIL  Al  *c 
K THE  ANL  Can  USE  lata  l-LPENUtM  CPiltPlA 


ACCESS  CCnTROL  PECRanISNS 
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71C0NWAV  ♦ MAXWFLL  ♦ NOPuaN 

• ON  ThE  IMPLEMENTATION  of  StClKIlY  -EASOFiES  IN  lNFt/RMAllC 
N SYSTEMS* 

MATRIX*  ROWS  Ah E LS<-HS,  CCLLMlob  APE  UAlA  ITtiib*  tLEMtNT 
IS  ACTHOMZATiUN  ACTION 


' 


access  control  mechanisms 

71COMPUVISCH 

ASAP  FILE  MAINTENANCE  AND  INECKh  a 1 1 On  PCTHltVAL  SYS  TEN*  HE 
FEHENCE  MaNLAL 

CONTROLS  ACCESS  TO  uOlNtL  ITems*  SYSIEh  F OnC  T IONS*  UEF 

INF.l  PROCESSES  * OEFINENEW  llfc^b  OH  HtCUKUS*  DA  1 A UEPFMJEnT  0*11 
ERIA 

ACCESS  PATH 
75HURRODGHS 

CMSII  DATA  ANT  STHOCTOKE  DEFINITION  l AFGUAGt  (UmSuL  > REF  t>E 
NCE  MANUAL 
DlRFCTt  CALC*  VIA 


ACCESS  PATH 
75TSICHHI r?IS 

LSLJ  A LINN  AND  SELECIuh  LANGLADE 

Dynamically  cpeateo*  r>  a i i\  i « i nf. i ) * .»*% u t’i-. s r rt-u 

-M 

ACCESS  PATH 
’ 76A$TRAHAN 

• SYSTFM  RS  (<  t L A T I U N a L APPROACH  TO  UATnbAbE  M ANaGEmEN  I * 

UEFIMTiCN  CF  INDEXES  ( ImAOFJS  ) AnU  Iivlth-EMIIY  kELAIIuivS 
HIPS  (LINKS ) 

.A 

ACCESS  PRIVILEGES 
7bGP IFF  I THS  ♦ WALt 

• AN  AOTHCH  1 2 A T ION  MtChAMSM  F'CK  a RELATIONAL  UATAHASE  SYS 

TEM^ 

. For  READ*  INSERT*  l.)LLfcrE»  UPDATE*  OH  ukoPIAlSo  in  T thr'S 

CF  all  OR  ALL  bUT) 

J APPLICATION  SYSTEM 

j 73MLNAMAKER  ♦ SWENSON  ♦ WHINbTUN 

• SPECIFICATIONS  FOR  TnE  IJEVtLCPMfc  ■*  I OF  A OENfcK *L  Utf)  OAIa 

BASF.  PLANNING  SYSTEM# 

AS  IT  PEL  A FES  TO  UMS 
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This  document  is  the  appendix  to  the  RFP  for  WWMCCS  (World  Wide  Military 
Command  Control  System). 

The  system  should  be  able  to  handle  six  data  structures  (it  is  not  clear 
whether  the  relationships  in  1,  2,  and  3 apply  to  group  types  or  group  inst  nces); 

1.  simple  hierarchy  — single  path  hierarchy  (1  parent,  1 dependent) 

2.  hierarchy  — tree  structure  or  multi -path  hierarchy  (1  parent, 
many  dependents) 

3.  inverted  hierarchy  — 1 subordinate,  many  parents 

4.  hierarchical  linked  — network 

5.  linked  list  --  physically  linked  group  repetitions  with  pointers 

6.  associative  linking  — links  based  on  content 


The  data  element  is  the  basic  data  item,  with  no  substructure.  Data 
elements  are  collected  into  groups  which  may  or  may  not  be  repeating. 


The  WWMCCS  calls  for  an  extensive  range  of  validity  checks  including: 
a range  of  values,  an  explicit  set  of  values,  table  look  up,  sequence  checks, 
format  consistency,  and  cross  comparison  (i.e.,  comparison  of  an  element  value 
with  other  values  in  the  data  base  for  consistency). 


For  selection,  qualification  should  include: 

1.  group  where  an  item  meets  a specified  boolean  selection 
expression  (BSE), 

2.  superior  where  EVERY  subordinate  meets  BSE, 

3.  superior  where  ANY  subordinate  meets  BSE, 

4.  all  subordinates  of  a qualified  group, 

5.  superior  based  on  qualification  of  subordinate  n levels 
removed, 

6.  any  groups  relating  to  group  (element)  meeting  BSE, 

7.  groups  meeting  secondary  BSE  wh°n  primary  BSE  not  met 
by  any  group. 
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For  presentation  of  results  report  generation  and  definition  capabilities 
including;  automatic  row  and  column  spacing,  paging,  titles,  headers,  footings, 
and  data  editing.  Reports  should  be  named  and  produced  on  demand  or  when 
triggered  by  specified  conditions. 

WWMCCS  calls  for  an  overlapping  seven  way  classification  of  files.  The 
overlap  is  because  some  of  the  dimensions  related  to  behavior,  some  to  processes 
on  the  files,  and  some  to  data  definition.  The  seven  classifications  are: 

1.  very  large  files 

2.  dynamically  changing  (maintenance  oriented) 

3.  static  files 

4.  growth  files 

5.  unformatted  text  files 

6.  small  data  element  files  (bits/bytes) 

7.  retrieval  oriented 

Categories  five  and  six  are  definitional  since  they  relate  to  data  format. 
Category  one  is  one  side  of  a size  dimension  which  relates  to  behavior.  The 
other  categories  (2,  3,  4,  7)  are  fuzzy  since  they  overlap  on  several  dimen- 
sions and  relate  to  both  behavior  and  process.  Maintenance  and  retrieval  are 
opposite  extremes.  Static  may  refer  to  either  content  or  size,  i.e. , no  changes 
or  only  value  modification  changes. 

Operations  on  the  database  are  classified  in  three  ways.  First,  five  types 
of  file  processing  are  defined: 

1.  defi niton 

2.  maintenance  (both  value  modification  and  insert/ delete) 

3.  retrieval 

4.  restructuring 

5.  output 

Second,  they  define  four  types  of  functions: 

1.  insert^! 

2 delete  / n0  distinctl0n  1s  made  element,  group,  or  entry 
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3.  change  — value  modification  on  a uniquely  identified  record 
instance 

4.  mass  update  --  stated  with  respect  to  changes,  but  could  also 
be  applicable  for  inserts  and  deletes 

The  third  set  of  classifications  can  be  inferred  from  their  five  types  of 
benchmark  jobs: 

1.  single  file  update 

2.  update  and  report  generation 

3.  multifile  report  generation 

4.  multifile  update 

5.  onl ine  retrieval 


The  system  requires  extensive  performance  monitoring  capability,  with  the 
option  to  turn  the  monitoring  on  or  off  on  demand.  Also  certain  system  status 
information  should  be  available  to  the  user,  who  should  have  the  option  of 
suspending  his  job  and  continuing  it  later. 
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ADS  is  a concise,  cross-referenced  system  for  definition  of  system  speci- 
fications and  communications  among  users,  systems  analysts,  and  programmers. 

A forms  (report,  input,  computational,  history,  and  logic)  driven  system  for 
capturing  much  data  and  process  defining  information  and  some  limited  behavioral 
data. 

1.  Report  --  defines  reports  by  specifying  headers,  data  items,  editing 
rules,  and  vertical  and  horizontal  positioning  information.  Cross-reference 
to  where  items  defined  (input,  computational,  or  history). 

2.  Input  — defines  input  records  with  item  name,  position,  size,  A/N 
(alpha/numeric  type  and  implied  left  and  right  justification),  validation  cri- 
teria (premises  only),  percent  of  the  records  for  which  the  item  is  present, 
and  a flag  to  indicate  if  a transaction  code  needed  to  identify  items.  Assumes 
set  of  independent  items  in  a flat  file. 

3.  Computational  --  provides  rules  for  generating  derived  items.  Specifies 
derived  item  name,  two  operands  (with  a cross-reference  to  their  original  defi- 
nition) and  an  operator. 

4.  Historical  — defines  Master  File  records.  Item  name,  percent  of 
records  where  item  occurs,  A/N,  maximum  size,  retention  (how  long  to  retain), 
and  cross-reference  to  original  definition. 

I 

5.  Logic  — premise  - action  definition  in  decision  table  form 

A 

i 

* Data  definition  (combination  of  logical  and  physical)  provided  on  input, 

historical,  and  computation  forms.  Assumes  single  type  of  input  and  single 
historical  record  formats  in  flat  file  structure.  Report  form  provides  report 
< definition. 
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Processes  are  defined  in  the  computational  and  logic  forms  and  implied 
in  the  report  form. 

Behavioral  data  only  as  percent  of  records  in  which  item  occurs.  When 
occurrence  100  percent,  no  system  implication  that  the  item  is  mandatory. 
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Early  work  calling  for  data  definition  standards.  All  business  data  pro- 
cessing applications  (whether  batch  or  online  and  management  or  operations 
oriented)  should  share  the  same  data  and  therefore  need  a common  data  definition. 
Common  definition  should  also  apply  for  the  many  DMS  that  are  being  developed. 
Once  his  data  is  defined  the  user  should  only  need  to  specify  what  he  wants  done, 
not  how  to  do  it.  Lists  a set  of  twenty  candidates  for  inclusion  in  data  defi- 
nition standard  (most  of  them  relate  to  physical  rather  than  logical  structure): 

(I)  file  name;  (2)  record  length;  (3)  blocking;  (4)  record  structure  variability 
(fixed  or  variable  length);  (5)  auxiliary  storage  device;  (6)  access  methods; 

(7)  tape  label  option  (standard  or  special);  (8)  record  type  of  segment  names 
(hierarchic  structure);  (9)  field  name;  (10)  starting  character  (position); 

(II)  field  size;  (12)  coding  type  (real,  binary,  etc.);  (13)  key/non-key  field; 
(14)  editing  rules;  (15)  networks  (defining  relationships  independent  of  how 
they  are  implemented);  (16)  encoding  (more  for  storage  efficiency  than  encryp- 
tion for  protection);  (17)  decoding;  (18)  security  access  control;  (19)  data 
validation  criteria;  and  (20)  dictionary  catalog  (at  file  level). 
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A Mars  III  datafile  is  a single  hierarchial  file  structure.  The  system 
can  handle  repeating  groups. 

Data  definition  includes  file,  data  item  index  and  encode/decode  table 
definitions.  File  definition  includes  privacy  codes,  unique  valued  primary 
index  item,  character  for  missing  data,  a record  compression  option,  percent  of 
records  containing  non-blank  data,  estimated  number  of  records,  space  alloca- 
tion for  growth. 

Data  item  definition  includes  maximum  number  of  occurrences  of  a repeating 
group  and  a privacy  code  with  a level  of  privacy. 

Index  definition  includes  the  form  of  the  index  (indexing  method),  is  index 
multiple  item,  when  index  is  being  defined  (before  or  after  database  creation), 
estimated  number  of  null  values. 

A subschema  can  be  defined  by  permuting  and  selecting  data  items. 

The  report  writer  allows  reports  to  be  printed  at  a certain  time  (daily, 
weekly,  at  an  interval,  or  on  a specific  date).  To  support  this  a user  can 
build  a calendar  specifying  year,  leap  years,  Sat.,  Sun.,  workdays,  and  holidays. 

Privacy  is  at  many  levels.  Users  have  an  identifier  and  a password.  Data 
items  have  a privacy  level  number.  Each  user  also  has  a privacy  level  number. 

A user  can  only  access  those  items  with  equal  or  lower  level  numbers.  A need 
to  know  flag  is  available  to  override  privacy  levels.  It  is  associated  with  a 
user  and  data  items.  In  this  way  a user  can  access  data  items  of  a higher 
privacy  level . 
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GIS  is  a DMS  which  supports  hierarchically  structured  files  and  offers 
a procedural  query  language. 

Data  definition  permits  column  headings,  editing  formats,  synonyms  for 
files  and  data  items,  and  an  encode/decode  table. 

Selection  clause  offers  substring  search  for  a string  in  a fixed  location 
of  an  item  or  anywhere  in  the  item,  inter-record  operators  which  determine  if 
an  item  has  increased,  decreased  or  changed  in  value  from  the  previous  record 
and  a test  for  empty  or  absent  data  in  an  item. 

Security  is  at  the  file  and  item  type  level.  Each  item  is  assigned  a 
security  code  which  is  also  assigned  to  each  password.  A user  may  only  use 
those  items  having  the  security  codes  assigned  to  his  password.  A file  is 
assigned  a password  and  can  only  be  used  if  the  user  knows  the  password. 

File  updating  is  a function  of  the  data  existing  or  not  existing.  If  a 
duplicate  record  is  being  added  the  user  can  ignore  it  or  add  the  duplicate. 

When  replacing  a record  the  user  can  ignore  update  if  record  doesn't  exist, 
replace  record  only  if  it  exists  or  add  or  replace  whether  it  doesn't  or  does 
exist.  Item  updates  follow  the  same  rules. 

GIS  provides  for  transaction  processing.  It  handles  file  reading  and 
searching,  and  field  mapping.  A transaction  is  read  and  the  master  file  is 
searched  for  a matched  record  on  that  key.  The  user,  in  a GIS  program,  controls 
how  the  update  is  processed. 
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Feature  Analysis  compares  ten  systems  on  a number  of  common  dimensions. 

The  ten  systems  are:  GIS,  MARK  IV,  NIPS/FFS,  TDMS,  UL/1,  COBOL,  DBTG,  IDS, 

IMS,  SC-1.  General  points  made  in  the  report  are:  (1)  the  host  versus  self- 
contained  systems  dichotomy  is  beginning  to  merge;  (2)  the  distinction  between 
the  procedural ly  oriented  programming  user  interface  and  the  non-procedural 
non-programming  user  interface;  (3)  the  importance  of  data  independence  and 
late  binding;  (4)  the  distinction  between  the  logical  data  structure  and  the 
physical  storage  structure  used  to  implement  the  logical  structure;  and  (5) 
most  existing  structures  are  hierarchical,  but  the  need  is  for  more  complex 
network  structures  in  the  future.  Data  structures  are  composed  of  a hierarchy 
of  elements  --  item,  group,  group  relation,  entry,  file,  and  database. 

Considerations  in  defining  the  data  item  include:  name,  length,  value 

set,  units  or  dimensions,  indications  of  existence  or  non-existence,  access 
locks,  usage  of  the  item,  whether  it  is  actual  or  derived,  I/O  editing  rules, 
and  whether  the  item  is  multivalued  or  not.  Considerations  for  defining  groups 
include:  whether  it  is  simple  or  compound  (composed  only  of  item  or  also  of 

other  groups),  whether  it  is  repeating  and  if  so  the  maximum  number,  whether 
or  not  duplicates  are  allowed  in  the  group  and  if  so  where  they  are  inserted 
(first  or  last),  whether  the  group  members  are  treated  as  a sef  or  whether 
they  are  ordered  on  some  key  and  if  so  how  they  are  ordered,  how  inserts  are 
done  to  the  group  (first,  last,  next,  prior,  or  ordered  based  on  some  key). 
Privacy  locks  can  be  applied  in  either  or  both  of  two  ways  --  by  data  element 
at  any  level  (item,  group,  file)  or  by  function  (for  read  only,  update,  insert, 
or  delete). 

Interrogation  and  update  is  based  on  a premise:action  pair.  The  premise 
is  a boolean  expression  involving  relationships  (equal,  not  equal,  less  than, 
greater  than,  etc.)  or  existence  and  may  refer  to  one  or  many  data  items.  The 
actions  which  can  be  specified,  while  they  have  much  in  common,  tend  to  be 
procedural  for  the  programming  user  and  ideally  non-procedural  for  the  non-pro- 
gramming user. 
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ID  YYAUTHOR:  71 CODASYL 

TITLE:  "Feature  Analysis  of  Generalized  Data  Base  Management  Systems" 


Updates  are  discussed  primarily  in  terms  of  transaction  processing.  The 
transactions  may  be  pre-defined  or  self-defining  (the  definition  included  with 
the  transaction).  A distinction  is  made  between  changing  an  item  or  a record 
versus  inserting  or  deleting  one.  Either  the  transactions,  or  the  master  file 
against  which  they  are  processed,  or  both  may  be  ordered  on  some  key. 
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ID  YYAUTHOR:  71COMPUVISOR 

TITLE:  "ASAP  File  Maintenance  and  Information  Retrieval  System 

Reference  Manual" 

ASAP  is  a flat  file  manager  which  can  handle  different  record  types.  Its 
language  is  procedural. 

Arrays  and  stacks  of  one  or  more  items  are  supported. 

Concatenation  of  text  is  normal  or  right  or  left  compress.  The  latter 
compress  or  remove  leading  blanks  from  the  right  operand  and  trailing  blanks  of 
the  left  operand  before  concatenation. 

Some  functions  provided  are: 

reverse  — reverse  the  values  in  a field  around  the  commas; 
useful  for  a persons  name 

dollar  — insert  a $ and  commas  in  a field 

change  — test  if  the  value  of  a field  has  changed  in  this  run 

bit  — extract  a bit  from  an  item 

An  update  process  can  make  a record  inactive  or  active.  A function  is 
provided  to  test  if  the  record  is  active  or  inactive. 

An  encode/decode  table  is  provided  with  internal  value  = external  value. 
The  right  and  left  side  have  separate  names.  A value  can  be  converted  by 
specifying  either  the  right  or  left  table  name.  The  value  is  converted  to  the 
opposite  sides  value.  The  word  "other"  in  either  side  specifies  the  code  for 
any  value  not  in  the  table.  If  one  side  of  the  table  is  numeric  and  increasing 
then  a greater  than  or  equal  (GE)  decode/encode  can  be  performed.  If  the  item 
is  GE  to  the  number  but  less  than  the  next  number  it  is  encoded  to  the  value 
associated  with  the  first  number. 

Tags  specify  actions  to  be  performed  when  a certain  event  occurs.  A tag 
tests  for  the  event  and  performs  the  actions.  All  tags  are  executed  at  the  end 
of  a run. 
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ID  YYAUTHOR:  7 1 COMPUV I SOR 

TITLE:  "ASAP  File  Maintenance  and  Information  Retrieval  System 

Reference  Manual" 

Security  mechanism  controls  access  to  the  system,  access  to  field  and 
records,  and  access  to  system  functions.  System  access  is  through  a user  name 
and  password.  Associated  with  this  are  access  to  system  functions  of  update, 
define  new  items  and  records,  use  of  defined  processes.  Each  item  can  have  a 
security  class  number.  Users  with  the  same  number  can  access  that  item.  Also 
a user  can  be  restricted  to  certain  records  (data  dependent  security)  by  a 
boolean  expression.  This  boolean  expression  is  concatenated  to  any  file  sec- 
tion expressions  the  user  uses.  Default  security  allows  limited  access  to  the 
file  and  is  very  restrictive. 
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ID  YYAUTHOR:  71CONWAY  + MAXWELL  + MORGAN 

TITLE:  "On  the  Implementation  of  Security  Measures  in  Information 

Systems" 

This  paper  discusses  the  problem  of  allowing  specific  users  access  to 
selected  portions  of  the  data  base. 

A security  matrix  is  proposed.  The  columns  are  data  items  — not  neces- 
sarily disjoint.  The  rows  are  users  and  an  element  is  a decision  rule  (read, 
write,  etc.).  Most  entries  are  denial  of  access  resulting  in  a sparse  matrix. 

The  matrix  is  used  as  follows: 

• a row  is  selected  to  authenticate  the  user 

• a subset  of  columns  in  this  row  are  selected  to  determine 
access  to  data  items 

• this  subset  remains  in  effect  during  the  entire  operation 

In  "batched"  transactions,  there  is  high  repetition  on  the  same  data  items. 
Security  check  should  take  advantage  of  this  for  efficient  operation.  The 
random  inquiry  has  low  repetition  and  could  tolerate  higher  overhead. 

Security  monitoring  should  detect  assaults  upon  the  system  (repeated 
attempts  to  enter  system).  A log  should  be  kept  of  successful  and  unsuccessful 
access  to  data  and  system. 

If  access  is  denied  to  an  item  (data  independent)  the  security  check  can 
be  performed  at  translation  time  thus  avoiding  routine  overhead. 

If  access  is  conditioned  (based  upon  values  of  the  item  or  other  items) 
then  access  must  be  checked  at  execution  time. 
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ID  YYAUTHOR:  71  HOFFMAN 

TITLE:  "The  Formulary  Model  for  Flexible  Privacy  and  Access  Controls" 


Simply  proposes  that  users  (Database  Administrators)  can  provide  their 
own  routines  and  procedures  for  access  control.  Provides  an  extension  of  the 
usual  table  look  up  and  password  form  of  security.  Anything  the  user  can 
program  can  become  part  of  his  access  control.  Assumes  all  access  control 
checks  will  be  made  at  run  time.  Ignores  the  fact  that  data  independent  (schema 
level)  checks  can  be  made  at  compile  time  for  improved  efficiency.  Interesting 
feature  is  that  it  allows  different  responses  when  different  users  get  a security 
violation.  Important  capability  since  the  response  the  user  gets  can  be  critical. 
Too  much  response  (e.g.,  you  aren't  allowed  access  to  salaries  over  $10,000)  can 
give  the  user  information  he  should  not  have,  while  too  little  information  (no 
salaries  over  $10,000)  can  introduce  errors  into  his  results. 

The  formulary  model  uses  a User  Control  Block  which  identifies  the  user 
and  links  him  to  the  various  access  control  or  "formulary"  routines.  The  user 
goes  through  a TALK  routine  to  the  ACCESS  routine  which  does  the  actual  data 
STORE  and  FETCH,  depending  on  the  response  of  the  CONTROL  routine.  The  formu- 
lary model  proposed  allows  for  virtual  addressing  of  the  data,  encrypting  and 
decrypting  of  the  data,  and  any  type  of  control  procedure  to  determine  if  the 
user  will  have  access  to  the  data.  If  he  is  not  allowed  access,  the  FETCH  and 
STORE  operations  in  the  ACCESS  routine  are  inhibited. 

Actually  the  model  is  even  more  general,  since  anything  the  user  wants  to 
code  and  pay  the  price  to  run  can  become  part  of  his  access  control  mechanism. 
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ID  YYAUTHOR:  71TONIK 

TITLE:  "Recovery  of  On-Line  Data  Bases" 


Looks  at  the  back  up  and  recovery  procedures  for  three  systems. 

1.  AMIS  — California  Department  of  Motor  Vehicles  Driver's  License  and 
Motor  Vehicle  Registration  Databases.  Approximately  35  million  records  and  1.3 
million  urgent  queries  per  month  (1971).  Non-urgent  queries  are  batched.  Four 
computers  are  connected  to  provide  the  entire  system.  There  is  an  automatic 
switch  over  so  that  when  one  fails  the  system  is  reconfigured  and  is  back  up 

in  90  seconds.  For  file  recovery  they  use  differential  dumps  (a  quarter  of 
the  database  is  dumped  each  week).  After  images  are  logged  for  any  track  that 
is  modified.  To  recover,  reload  the  last  correct  after  image  and  reprocess 
from  that  point.  Six  senior  operators  are  regularly  assigned  to  back  up/re- 
covery operations. 

2.  Pillsbury  — is  primarily  an  online  retrieval  and  batch  update  system 

with  primarily  old  mature  applications.  Types  of  failure:  (1)  application 

abort;  (2)  operating  system  or  hardware  failure;  (3)  disk  unreadable;  and  (4) 
erroneous  update.  If  recovery  is  not  automatic,  visibility  is  important  so  that 
errors  can  be  caught  early  before  they  are  propogated  through  the  database. 

For  recovery  they  use  daily  dumps  with  overlapping  retention  (daily,  weekly, 
monthly,  annual).  The  system  journal  is  used  for  both  accounting  audit  and 
system  recovery.  Log  includes  transactions  and  before  and  after  images. 

When  application  aborts,  journal  closed,  database  placed  in  abort  status  and 
inaccessible  until  recovery.  They  estimate  their  roll  back  procedures  three 
times  faster  than  reload  and  reprocess.  Recovery  statistics: 

• 6 single  job  aborts/week 

• .5  erroneous  updates/week 

t 2.5  hardware/software  failures/  week  affecting  one  or  more 
data  base  jobs 
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ID  YYAUTHOR:  71TONIK 

TITLE:  "Recovery  of  On-Line  Data  Bases" 

3.  Ohio  Bell  — an  online  retrieval  and  update  system  with  1200  files  and 
8000  to  9000  transactions  daily  with  transactions  averaging  200  file  accesses. 
The  entire  data  base  is  dumped  nightly  and  stored  off  site.  Logs  are  maintained 
with  transactions,  before  and  after  images.  Four  levels  of  errors:  (1)  commu- 

nications errors  — data  not  accepted;  (2)  input  validation  errors  --  data  not 
accepted;  (3)  abort  during  a transaction  — automatic  roll  back  using  before 
images;  and  (4)  errors  discovered  after  the  transaction  has  completed  or  not 
related  to  a transaction  (hardware/software  failures)  — manual  system  restora- 
tion required.  Three  types  of  level  4 system  restorations:  (1)  short  term  — 

go  back  to  the  last  time  point  and  write  before  images  of  all  uncompleted 
transactions  and  reprocess;  (2)  to  back  to  any  specified  time  point  (determined 
manually)  write  before  images  and  reprocess;  (3)  long  term  --  reload  and  repro- 
cess. 


Quantities 

of  errors  by  type: 

level 

ty£e 

number  of  errors 

1 

communications  errors 

190/day 

2 

input  validation  errors 

140/ day 

3 

abort  during  transaction 

250/day 

4 

system  restoration  (short) 

23  in  6 months 

4 

system  restoration  (medium) 

3 in  6 months 

4 

system  restoration  (long) 

1 in  2 years 

This  is  one  of  the  few  articles  that  gives  any  error  statistics.  Such  statis- 
tics are  important  behavioral  characteristics  which  will  help  determine  re- 
covery procedures. 
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ID  YYAUTHOR:  72DANA  + PRESSER 

TITLE:  "An  Information  Structure  for  Data  Base  and  Device  Independent 


Report  Generation" 

Two  problems  with  current  output  specification:  (1)  too  few  defaults  for 

user;  and  (2)  device  dependent.  Proposes  solution  in  terms  of  logical  (speci- 
fied by  user)  and  physical  (device  dependent)  report  definition  and  a system 
mapping  between  them.  If  LRU  (logical  report  unit  — page  size)  greater  than 
PRU,  then  logical  page  broken  up  vertically  or  horizontally  or  both.  If  LRU 
less  than  PRU,  then  pages  may  be  combined.  Should  be  defaults  for  these  mapping 
which  the  user  could  override.  Even  if  PRUs  same  size,  different  mappings  needed 
for  hard  and  soft  copy.  With  hard  copy  could  use  fold-out  pages  or  look  at 
multiple  pages  simultaneously. 

User  specifies:  (1)  formatting  — page  dimensions,  header  and  trailer 

labels,  and  row  and  column  spacing  (either  in  absolute  or  relative  terms);  (2) 
actions  (input,  output,  computation,  and  test)  to  be  taken  to  generate  the 
report;  and  (3)  specification  and  definition  of  the  items  to  be  included.  Re- 
lationship between  (3)  and  the  data  base  definition  of  the  items  is  not  clear. 
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TITLE:  "Details  of  A Scientific  Approach  to  Information  Systems" 


Three  strategies  to  study  information  systems:  (1)  look  at  and  analyze 
"real  world"  systems;  (2)  develop  taxonomy  for  "real  world"  systems;  and  (3) 
develop  and  analyze  models  of  information  systems.  Actually  a sequence  of 
steps,  but  little  progress  beyond  step  two.  Two  major  areas  to  consider  in 
studies:  (1)  function  — what  should  the  system  do;  and  (2)  efficiency  — how 

does  the  system  do  it  and  how  well.  Most  work  in  the  area  of  efficiency. 
Systems  hierarchy: 

1.  users  job  --  a set  of  transactions  to  be  processed 

2.  application  procedures  --  what  needs  to  be  done 
(procedure  oriented) 

3.  Information  Management  System  — data  structures  and 
logical  access  paths 

4.  operating  system 

5.  physical  access  methods 

6.  hardware 

For  strategy  three,  need  a generalized  simulation  model  which  will  allow  you 
to  define  the  user's  job  stream  of  transactions  and  procedures  (assumption  that 
data  access,  not  actual  processing,  is  the  time  consuming  part  of  the  opera- 
tions --  business  not  scientific  applications).  At  the  information  systems 
level  need  to  specify  data  structures  and  logical  access  paths.  Of  the  three 
basic  structures  (hierarchy,  entity  set  description  (similar  to  relational) 
and  binary  relations)  the  second  method  was  used.  This  is  the  only  type  of 
structure  simulated. 

j 

Points  made  in  the  article  are  the  underlying  rationale  for  FOREM  (and 
later  PHASE  II),  which  simulates  systems  performance  once  the  user  has  defined 
his  applications,  data  structure,  and  hardware.  Parameters  which  the  user  must 
^ specify  for  the  simulation  are  a subset  of  what  he  must  specify  for  data  defi- 

nition, patterns  of  processing,  and  the  behavior  of  both  the  data  and  the  pro- 
cesses. Also  some  of  the  simulation  results  will  be  fed  back  into  the  design 
. database  as  improved  performance  estimates. 
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ID  YYAUTHOR:  72TIECHROEW 

TITLE:  "A  Survey  of  Languages  for  Stating  Requirements  for  Computer- 

Based  Information  Systems" 


Focuses  or  how  to  specify  information  systems  requirements.  Three  phases 
in  development  --  analysis,  design,  and  construction.  Emphasis  of  paper  is  on 
how  needs  are  documented  and  transferred  from  the  analysis  to  the  design  phase. 
The  purpose  is  to  reduce  the  distance  between  the  person  with  the  problem  or 
ultimate  user  and  the  computer. 

Must  distinguish  between  Business  Data  Specification  Functions  (BDSF)  and 
Data  Processing  Functions  (DPF).  The  difference  is  between  what  to  do  and  how 
to  do  it.  Problem  with  general  purpose  programming  languages  is  that  they  mix 
the  two  types  of  statements  (specifying  that  a report  needs  to  be  ordered  on  a 
particular  variable  is  not  the  same  as  specifying  to  sort  it).  The  BDSFs  pro- 
vide a high  level,  user-oriented  set  of  patterns  of  processing. 

There  is  a need  for  a high  level  requirements  statement  language  to  pro- 
vide a formal  method  of  documentation  during  the  analysis  phase.  The  paper 
compares  a number  of  such  requirements  statement  techniques,  ’eluding  ADS, 

TAG,  Information  Algebra,  Systematics,  and  the  works  of  Young  and  Kent,  Lange- 
fors , and  Lombardi.  The  comparisons  are  on  how  the  problem  is  defined,  how  the 
output  is  defined,  and  the  data  and  computational  relationshi ps . Few,  if  any, 
of  these  systems  are  used  to  any  great  extent,  partly  for  technical  reasons 
(they  aren't  satisfactory  for  stating  requirements)  and  partly  for  lack  of 
acceptance  by  the  analyst  (part  of  which  may  be  due  to  all  the  systems'  in- 
adequacy in  expressing  complete  requirements). 

Teichroew  proposes  a set  of  three  objectives  for  Requirements  Statement 
Languages.  First,  it  must  be  able  to  handle  both  current  and  future  require- 
ments (including  changes  in  hardware,  number  and  relationships  among  users, 
more  integrated  data  structures  (databases)  and  less  predictable  ad  hoc  uses). 
Second,  the  language  should  be  easily  used  as  part  of  the  necessary  activities 
for  determining  the  stating  requirements.  The  language  should  be  usable  by 
the  end-user  as  well  as  the  analyst,  allow  a top  down  approach,  and  aid  the 
user  in  determining  the  implications  of  his  requirements  on  system  performance. 
Third,  "the  language  should  be  suitable  for  building  the  system  to  accomplish 
the  requirements." 

PSL  (Problem  Statement  Language)  is  an  attempt  to  provide  these  features. 

P.2 


v -irr-  '*&;<**■ 


1 


IC  YYAIjThCR-*  73Clf  S'-ui  c. 

TITLE — * COMPOS! T 77  UScnS  ho  IuT. 

PlfeLISRE* --- — lui'  SPARE*  IwL. 

PLBLIShEm  LCCaT  10N-*  «imK  Awb^K,  i , 

YEAR---------------*  i*/j 

AUTHOR  NANO*  COP  bRAKR 

first  nape--*  im;. 

DESCR  IPTCR--*  OAT  AHA jt  VAN  A Gt  M '« I SYSTtM 

DESCRIRT  1 C iv  - « OMY  AoCrSSto  v 1a  GMIi\Et  T 1 N t an  ah  1NG  F/.LlLilY 
DESCRIPTOR--*  data  SlHUCTLHE 

DESCRIPTION-*  FLAT  F iLt < SlRoL L uh  CUURUIima  ( tUJ 

DESCR IPTCR--*  TATA  Ilth  DErlflTiON 
DESCRIPTION-*  FNLOuE-OLCOL/t  AM  tt\CKYPfiOi‘ 

DESCRIPTOR — « CREATION 

DE SCRIPT  I C i\-*  PL lL b ruh  hMixul  1 1 - m pISSIng  DaTm 
DESCR  IPTCR--*  FILE  LtW  L.  UEkIvaTILk 

DESCRIPTION-*  SLCH  STATISTICAL  oMPUT*  COK«E  L a f ION  * A N 0 KEC-kESSICN 

DESCRIPTOR--*  GRAPhIoAl  OLIPLl 

DESCR  IPTCR--*  FCRRmIxON  am.  RR(;  StivT  a T Ion 
DESCRIPT  ICn-*  T A h U L a h » T*0  U I OH-o  L Ob  AL  * GRAPHICAL 

DESCRIPTOR--*  FRCObt/oe  0(/Ut 

DESCRIPTOR--*  F.NCKYPIlON 


83 


flL  ■*? 


*«r 


It 


AUTHOR:  73COMSHARE 

Composit  77  Users  Guide 

v i i : : p o s i t is  flat  file  manager  with  single  fixed  length  record  types.  It 
a procedural  language  with  many  operations. 

ta  items  are  defined  with  codes  for  missing  values  and  a scramble 
(this  item  will  be  scrambled). 

\ r.omposit  file  is  created  using  a data  file  and  a specification  file. 

ification  file  describes  the  format  of  the  data  file  --  data  is  in  free 
'\ed  field  format,  record  to  begin  read,  number  of  records  to  read,  input 
per  record,  an  end  of  record  character,  a field  separator,  and  the  method 
j -d ling  the  file  --  a scramble  code,  treatment  of  empty  (blank)  lines 
or  ignore  between  records). 

trieval  generates  a hit  file  which  can  be  further  processed  in  a 
frirted  way. 

ord  selection  has  multiple  AND  and  OR  predicates.  Multiple  OR  selects 
tern  having  many  values  while  multiple  AND  selects  on  several  items  having 
■ lie  value.  A range  function  and  a range  function  with  an  increment  are 

provided. 

displaying  data  the  format  defaults  to  columns  with  item  names  as  titles, 
options  include  treatment  of  negative  values  (CR,  minus  sign  or  in 
:es i s ) , treatment  of  zero  values  (blank,  zero  or  dash  [-]),  literals  are 
iiuwed  in  the  items  list,  row  numbering  for  output,  lines. 

A prompting  option  is  provided  for  updating  the  file.  When  adding  records, 
’•em  prints  the  record  number,  the  item  name  and  asks  for  its  value.  When 
values  it  prints  the  item  name  and  old  value  and  asks  for  a new  value. 

file  can  be  altered  or  converted  by  reordering  records,  permuting  items, 
r removing  items,  changing  the  description  of  an  item,  changing  an  items 
its  missing  values. 
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Secondary  files,  similar  in  structure  to  the  main  file,  are  supported. 
These  files  can  be  joined  (1  to  1 ) on  a common  field  with  mismatches  ignored 
and  can  be  combined  using  a logical  AND  or  OR  on  a cormion  item.  These  files 
can  be  sa-ed  and  later  attached  for  use.  Also,  the  status  of  files  can  be 
printed,  item  descriptions  when  file  created,  when  updated  and  the  number  of 
records  in  the  file. 
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Must  have  an  operational  definition  of  security  before  real  progress.  IBM 
working  with  three  installations  (TRW,  MIT,  and  State  of  Illinois  Management 
Division)  to  study  three  problems:  (1)  technology  involved  in  security;  (2)  to 

install  a system  which  is  "relatively"  secure,  although  not  completely  so;  and 
(3)  to  evaluate  that  system  against  the  technology.  Work  has  identified  three 
types  of  environments:  (1)  those  involving  defense  and  national  security;  (2) 

those  involving  internal  corporate  management  information  and  product  develop- 
ment; and  (3)  the  commercial  privacy  environment  (unclear  whether  this  includes 
both  large  commercial  credit  or  insurance  databases  with  a limited  number  of 
user  and  computer  utilities).  Certification  is  discussed  with  respect  to 
certifying  a standard  level  of  performance  (analogy  made  to  30  minute,  one  hour 
and  ten  hour  safes  as  being  secure  in  terms  of  fixed  criteria).  Must  also  con- 
sider economic  trade  off  between  cost  of  security  and  cost  if  data  compromised. 

As  part  of  his  problem  definition  the  user  must  define  the  level  of 
security  required  by  his  procedures  and  data.  However,  he  should  be  unconcerned 
how  those  requirements  are  implemented,  except  to  insure  that  those  requirements 
are  met  (this  is  the  need  for  certification).  Another  approach  would  be  for  the 
user  to  provide  some  indication  of  the  consequences  if  his  data  is  compromised 
and  allow  the  system  to  select  the  appropriate  level  of  security  from  its  various 
al ternatives. 
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Key  to  database  sharing  is  simultaneous  access.  Limits  are  required  to 
prevent  concurrent  updates,  but  they  create  potential  for  deadlock.  DBTG's 
use  of  KEEP-FREE  avoids  deadlock,  but  places  integrity  burden  on  user  --  dangerous 
approach.  Requirements  for  data  driven  applications  too  unpredictable  for  usual 
deadlock  prevention  methods. 

Proposes  two  mechanisms.  LOCK/UNLOCK  — used  by  process  to  indicate  it 
will  want  sole  access.  ALLOCATE/DEALLOCATE  — used  to  identify  the  actual  data 
items  needed.  LOCK  creates  a "lock  list"  for  a process.  ALLOCATE/DEALLOCATE 
attaches  and  removes  items  from  the  lock  list.  Deadlock  (as  opposed  to  a tem- 
porary block)  occurs  when  the  data  base  state  graph  (represented  by  all  lock 
lists)  contains  a loop.  Tracing  the  lock  lists  will  identify  both  the  processes 
which  are  deadlocked  and  the  item  over  which  they  are  deadlocked. 

Recovery  involves  restarting  a process  at  its  last  checkpoint,  which  was 
automatically  taken  when  the  LOCK  was  issued.  However,  data  base  does  not  need 
to  be  recovered  because  it  is  not  changed  until  DEALLOCATE.  Can  restart  either 
process,  depending  on  system  criteria  (e.g.,  shortest  lock  list,  lowest  prior- 
ity, etc.). 

Authors  undecided  whether  LOCK  and  ALLOCATE  should  be  explicit  command  or 
implicit  in  part  of  other  commands.  Important  that  read  only  process  should 
also  have  option  to  LOCK  and  ALLOCATE.  Mechanisms  only  mandatory  for  data 
dependent  updates. 
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TITLE: 


"Specifications  for  the  Development  of  a Generalized  Data  Base 
Planning  System" 


Wants  a system  which  as  a result  of  a query  can:  (1)  retrieve  the  data 

needed  to  answer  the  query;  and/or  (2)  set  up  the  application  program  or  model 
that  must  be  run  to  answer  the  query.  Data  base  systems  ease  the  first  step, 
but  users  also  need  the  second  step.  GPLAN  (Generalized  Database  Planning 
System)  proposed  as  such  a system.  It  is  a synthesis  of  four  components: 

(1)  NAPSS  — Numerical  Analysis  Problem  Solving  System;  (2)  SODA  — Systems 
Optimization  and  Design  Algorithm;  (3)  GDMS  --  Generalized  Data  Management 
System;  and  (4)  OPTIMA  — a mathematical  programming  and  optimization  system. 
NAPSS  and  SODA  are  similar  in  that  they  both  have  a number  of  algorithms  and 
automatically  select  the  best  one  for  the  application.  Under  GDMS  he  discusses 
four  systems:  System/2000,  RAMIS,  IMS,  and  DISK  FORTE. 

Lists  nine  components  of  a Generalized  Database  Planning  System:  (1)  a 

GDMS  to  allow  input,  search,  storage,  maintenance,  retrieval,  and  output;  (2) 
the  actual  data  in  the  database;  (3)  a query  language  which  will  allow  queries 
against  the  data  base  and  provide  directives  to  the  application  packages  and 
models;  (4)  an  analyzer  for  the  query  language;  (5)  a collection  of  application 
packages  and  models;  (6)  an  administrative  report  module;  (7)  user  interface; 
(8)  a set  of  extraction  files  as  intermediaries  between  the  database  and  the 
application  packages  (definition  of  the  content  and  structure  of  the  files  and 
how  they  are  used  by  the  various  applications);  and  (9)  the  users  (two  types  — 
(a)  the  technical  computer  systems  oriented  personnel  and  (b)  the  non-techni cal 
administrator  or  manager  who  has  the  planning  application). 


This  is  one  of  the  few  articles  that  addresses  both  the  database  and  the 
applications  side  of  the  entire  problem  — solving  the  user's  problem.  Because 
of  the  complexity  of  the  analysis  and  results  there  is  also  an  emphasis  on  the 
use  of  graphic  rather  than  tabular  output.  In  summary,  the  GPLAN  attempts  to 
do  for  planning  what  ISDOS  tries  to  do  for  computer  systems  design. 
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Model  204  is  a complete  (self-contained  and  hosted)  retrieval  and  update 
system  which  can  be  used  in  a batch  or  online  environment.  It  uses  a single 
flat  file  structure  with  limited  repeating  group  or  multivalued  item  capability. 
Although  a Model  204  database  can  contain  up  to  255  files,  only  one  can  be 
opened  at  any  time.  It  uses  IFAM  (Inverted  File  Access  Method)  and  allows  four 
logical  access  paths;  inverted,  direct,  sequential,  and  linked  or  chained. 

The  user  has  only  logical  data  definition  capabilities;  name,  type,  and 
if  the  field  is  repeating  the  maximum  number  of  occurrences.  The  type  is  a 
composite  of  several  categories: 

« key  (default)  or  non-key 

• invisible  --  user  specified  pointer  which  cannot  be 
printed 

• numeric  --  character,  binary,  or  coded 

• date 

• suppress  FRV  (for  each  value)  --  used  when  values  are 
almost  unique 

Names  are  automatically  encoded,  as  are  values,  when  their  lengths  are  variable. 

Records  are  selected  based  on  item(s),  value(s),  or  range(s).  For  repeat- 
ing or  multivalued  items  the  default  is  to  consider  only  the  first  item,  but 
there  is  an  option  to  let  the  selection  be  on  ANY  of  the  item  values.  The 
system  will  return  either  the  selected  set  of  records  or  a list  of  pointers. 

The  list  can  be  concatenated  with  or  processed  against  other  lists.  Selection 
can  only  be  on  keyed  items. 

Updates  to  the  database  can  include  value  modification  of  items  or  adds  or 
deletes  of  either  items  or  records.  For  multivalued  items  adds  are  done  to 
the  end  of  the  set.  For  value  modification  the  default  is  to  change  only  the 
first  item,  but  this  can  be  overridden  by  specifying  change  any  item  with  valuel 
to  vaiue2.  This  form  of  change  can  also  be  used  with  non-repeating  items. 
Similarly,  you  can  delete  all  of  the  repeating  items  or  only  those  with  a cer- 
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tain  value.  For  update  protection  the  system  locks  at  the  file  level.  Requests 
are  classified  as  update,  retrieve  only,  or  non-file.  During  an  update,  re- 
trievals and  other  updates  are  locked  out.  There  is  also  an  AUDIT  command  which 
prints  out  an  "audit  trail"  with  a set  of  user  specified  items. 

The  user  can  define  and  save  his  own  processes  or  SEGMENTS  which  he  can 
later  invoke  with  a set  of  parameters.  The  user  can  output  items  in  a default 
format  by  just  giving  its  name.  However,  there  are  also  extensive  report  defi- 
nition capabilities  in  the  system. 
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ID  YYAUTHOR:  76HAMMER 


TITLE:  "Data  Abstractions  for  Data  Bases" 

The  premise  is  that  a user  should  view  the  data  base  in  behavioral  terms. 
He  should  be  concerned  with  the  behavioral  semantics  of  data  and  not  so  much 
with  its  structure.  This  approach  will  provide  a greater  degree  of  data  in- 
dependence. 

By  limiting  access  to  the  data  base  to  a few  semanticly  meaningful  opera- 
tions the  user  is  isolated  from  the  data  structure.  In  an  employee  data  base 
they  may  be  HIRE,  FIRE,  GIVE  RAISE,  etc. 

This  concept  also  protects  the  data  base  by  limiting  access  to  data  and 
preserving  its  integrity. 


The  problems  of  this  approach  are: 

• a database  is  defined  in  terms  of  data  not  in  terms 
of  operations 

• new  operations  develop  after  the  data  base  has  been 
defined 


Issues  for  resolution: 

• not  all  interactions  to  the  data  base  can  be  defined 
as  abstract  operations 

• a users  view  and  use  of  the  database  changes  over 
time  — the  operations  must  evolve 

• different  users  may  define  different  operations  on 
the  same  schema  (subschema).  It  must  be  assured  that 
these  operations  are  consistent  with  other  subschemas 
and  that  they  do  not  interfere  with  each  other. 
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ID  YYAUTHOR:  74LEAVENW0RTH  + SAMMET 

TITLE:  "An  Overview  of  Non-Procedural  Languages" 


This  article  gives  some  characteristics  or  features  of  very  high  level 
languages. 

A very  high  level  language  (VHLL)  is  a prescription  for  solving  a problem 
without  sequence  of  statements. 

It  is  relative  to  its  predecessors.  The  definition  of  VHLL  changes  de- 
pending upon  what  previous  languages  have  done. 

VHLL  can  contain  both  high  level  and  low  level  features. 

1.  Associative  referencing:  data  is  accessed  based  upon  its  properties 

(content,  etc.). 

2.  Aggregate  operators:  operators  upon  the  whole  data  structure  rather 
than  an  item  or  a record  at  a time. 

3.  Elimination  of  arbitrary  sequence:  for  a specific  problem  the  order 

of  statements  is  irrelevant.  Elimination  of  assignment  statements, 

GO  TO's,  and  temporary  variables. 

4.  Nondetermini  Stic  and  parallelism:  a free  choice  of  statements  with 

multiple  paths  in  a statement(s). 

5.  Pattern  directed:  perform  functions  based  upon  a pattern  in  the 

data  --  similar  to  associative  referencing. 
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TITLE:  "Basic  Operations  on  Information  as  a Basis  for  Data  Base  Design" 


Basic  goal  is  to  aid  analysts  in  moving  away  from  implementation  oriented 
tools  toward  a more  information  theoretic  approach  --  focusing  more  on  what 
needs  to  be  done  rather  than  on  how  to  do  it.  From  the  user's  point  of  view 
database  design  consists  of  deciding  what  data  to  include  in  the  database  and 
what  operations  to  perform  on  the  data  to  produce  meaningful  information. 

Real  world  is  composed  of  entities,  attributes,  and  values.  Attributes  may 
describe,  identify,  or  relate  entities.  Describing  and  relating  attributes 
have  a one  to  many  relationship  with  entities,  whereas  identifying  attributes 
are  normally  one  to  one.  A domain  defines  the  formal  value  set  of  an  attribute, 
although  many  attributes  may  share  the  same  domain. 

Out  of  the  total  attribute  space  only  a certain  subset  of  attributes 
apply  to  a particular  entity  or  entity  type.  This  defines  the  entity's 
relevant  attribute  space.  An  information  element  is  composed  of  an  entity, 
an  attribute,  and  a value.  Information  elements  are  grouped  into  information 
sets.  Three  types  of  information  sets:  (1)  isotypic  - set  of  entity,  attribute, 

value  triplets  where  the  entities  have  the  same  attribute,  although  not  neces- 
sarily the  same  value  for  that  attribute;  (2)  isonymous  - the  set  refers  to  the 
attribute  value  pairs  for  the  same  entity;  and  (3)  homogenous  - is  a flat  file 
containing  specified  set  of  attribute  value  pairs  for  a given  set  of  entities. 

The  concepts  are  best  pictured  as  a matrix  where  the  rows  are  entities,  the 
columns  are  attributes,  and  each  cell  contains  a value.  Isotypic  select  is 
of  a column.  Isonymous  selection  is  of  a row.  A homogenous  information  set 
is  a combination. 

Lindgreen  defines  seven  operators  --  six  binary  set  operators  and  one 
monadic  operator. 

1.  Inclusion  combines  two  Homogenous  Information  Sets  (HIS).  It 
operates  on  flat  files  and  simply  appends  records  of  the  same 
type. 
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2.  Extraction  isolates  one  or  more  isonymous  sets  (since  isonymous 
sets  refer  to  the  same  entity  this  operator  in  effect  selects 
one  or  more  entities).  It  operates  on  a flat  file  and  selects 
records. 

3.  Conglomeration  operates  on  multiple  flat  files  to  combine  records 
for  the  same  entity.  In  effect  it  concatenates  multiple  segments 
of  a record.  It  is  similar  to  inclusion,  except  that  it  operates 
on  attributes  instead  of  entities.  In  terms  of  the  matrix  — in- 
clusion combines  rows  into  a series  of  records  or  a file,  whereas 
conglomeration  combines  columns  into  a single  records. 

4.  Separation  is  similar  to  extraction  except  that  it  operates  on 
attributes  (columns)  instead  of  entities  (rows).  It  is  analogous 
to  the  projection  relational  operator. 

5.  Derivation  defines  the  value  of  an  attribute  in  terms  of  one  or  more 
other  attributes.  It  yields  an  isotypic  set  where  the  entities  have 
a common  attribute.  This  operator  in  effect  provides  the  derivation 
rule  for  a derived  attribute. 

6.  Detection  is  similar  to  derivation  except  that  it  uses  a boolean 
selection  expression.  While  derivation  tells  how  to  calculate 

a value,  detection  asks  is  the  value  equal  to  a specified  value. 

7.  Exposition  is  a many  to  one  operator.  It  is  a file  level  derivation 
operator,  e.g.,  a summation. 


Since  all  information  processing  cannot  be  described  completely  by  this 
set  of  operators  it  is  still  incomplete,  but  it  is  a beginning  for  the  approach 
Lindgreen  favors. 
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ID  YYAUTHOR:  74LISKOV  + ZILLES 

TITLE:  "Programming  with  Abstract  Data  Types" 

An  abstract  data  type  is  defined  as  a class  of  objects  which  is  charac- 
terized by  the  operations  available  on  it.  It  is  a mechanism  for  defining 
data  and  the  legal  operations  on  the  data.  The  data  can  only  be  accessed  by 
invoking  the  operations  defined. 

The  term  abstract  means  the  user  need  not  know  the  physical  structure  of 
that  data  or  the  way  the  operations  on  the  data  are  implemented.  He  need  only 
know  the  logical  conceptual  data  structure  and  what  the  operations  do  to  this 
logical  structure. 

An  operational  cluster  (similar  to  the  CLASS  structure  in  Simula)  is  de- 
fined as  a TYPE.  It  consists  of  local  data  structures  and  operations  on  these 
local  data  structures.  There  is  an  operation  to  initialize  the  local  data. 

A variable  is  declared  to  be  of  this  cluster  type.  The  only  way  to  access 
and  manipulate  data  of  this  type  is  through  the  operations  defined  in  the 
cluster. 
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TITLE:  "On  Interaction  with  Data  Bases" 


Data  bases,  as  opposed  to  files,  have  an  intrinsic  meaning  independent  of 
their  users.  These  are  the  formal  specifications  of  data  base  properties  (D- 
rules).  Integrity  rules  specify  domain  and  consistency  constraints  and  excep- 
tion actions  to  be  taken  when  constraints/premises  fail.  Privacy  rules  deter- 
mine what  users  can  do  to  the  data  base  and  what  information  they  can  get. 

Two  ways  to  specify  and  insure  integrity:  (1)  functional  specification  — 

define  premises  and  test  whenever  an  item  is  modified;  or  (2)  constructive 
specification  — define  a set  of  "legal"  operators  or  primitives  which  guarantee 
valid  results.  Minsky  favors  constructive  specification  because:  (1)  it  avoids 

performance  penalties  from  constantly  testing  premises;  and  (2)  it  solves  the 
problem  of  allowing  the  data  base  to  move  through  temporarily  invalid  states 
while  processing  a transaction.  Primitives  for  data  bases  still  need  to  be 
defined  since  the  ones  for  files  (update  and  retrieve)  are  not  appropriate. 

For  security,  access  control  is  not  enough.  Need  control  at  both  the 
schema  and  instance  level.  For  example,  user  may  be  allowed  an  item  only  if 
it  has  certain  values.  Minsky  links  this  level  of  control  to  SIMULA'S  class. 

Much  of  Minsky's  objection  to  functional  integrity  based  on  performance 
implications.  He  assumes  must  always  test  premise,  but  part  of  definition  may 
specify  when  to  test  (see  Eswaran  and  Chamberlin).  If  his  primitives  were 
developed,  they  might  provide  the  basis  for  the  patterns  of  processing. 
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01 le  gives  some  design  considerations  for  interfacing  a nonprogrammer  to 
a database.  He  does  this  in  the  light  of  what  the  user  must  know  before 
interfacing  to  the  data  base.  If  a syntax  is  simple  the  semantics  could  be 
complex.  A trade  off  is  considered  in  terms  of  simple  syntax  but  complex 
semantics.  This  implies  more  knowledge  by  the  user. 


The  major  points  are: 

1.  The  nonprogrammer  should  not  be  reguired  to  control 
processing  time  trade-off.  This  requires  more  knowledge 
about  physical  and  logical  structure. 

2.  If  user  has  a high  degree  of  control,  he  needs  more  knowledge 
and  system  becomes  complex  to  use. 

3.  premise/action  mix 

limit  to  < actions  < premise:*  or 
< action:*  ...<action^»  <premise> 
one  or  many  actions  on  a single 
subset  of  the  data  base  (complex 
syntax) 

4.  The  more  complex  a data  structure  (hierarchy,  network) 
that  is  processed,  the  more  knowledge  is  required  and 
the  more  complex  the  syntax. 

5.  Selection  facilities  should  be  same  in  update  and  query. 
Implies  a consi stent  syntax  across  functions  requiring 
less  knowledge  to  use. 


Optimal  language  design  is  with  a simple  consistent  syntax  (easier  to 
learn  and  use)  but  with  easy  to  understand  semantics  (function  takes  few  paths). 


Cognizance  factors: 

1.  mandatory  --  user  must  know 

2.  optional  --  user  may  know 

3.  hidden  --  user  shouldn't  know 
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Data  Analyzer  is  a well-organized,  self-contained  retrieval  system  for 
processing  a single  flat  file  or  up  to  six  coordinated  flat  files.  It  can 
include  either  fixed  or  variable  length  records.  It  is  a form  driven  system 
with  separate  sections  for: 


1. 

application  (names  the  file) 

2. 

report  title 

3. 

record  selection 

4. 

sort  and  control  totals 

5. 

compu tat ions/ CALL S/opt ion si  features 
file  level  derivations) 

(including 

entry  and 

6. 

print  specifications  (extraction  and 
if  default  options  not  used) 

formatting 

specifications 

Data  definition  defines  the  physical  layout  of  the  records.  Limited  use 
of  four  character  repeating  group  or  multi-valued  items  which  can  be  used  only 
for  selection.  The  user  specifies  the  name,  fixed  starting  position,  type 
(character,  packed  decimal,  or  binary),  output  default  column  heading,  and 
value  editing  information.  If  there  are  multi-valued  items,  the  user  also 
specifies  the  maximum  number  of  occurrences  per  record. 

The  basic  pattern  of  processing  is  for  the  user  to  select  a subset  of 
records  and  process  them.  Selection  can  be  based  on  one  or  many  data  items 
and  can  look  for  a specific  value  or  a range  of  values.  For  multi-valued  items 
all  items  are  tested  for  the  condition  and  if  any  are  found  the  record  is 
selected.  Given  a set  of  records  the  user  can  specify  the  sequence  for  them. 
Also  he  can  specify  desired  control  totals  and  do  special  processing  on  any 
control  breaks.  Within  Data  Analyzer  the  user  has  limited  computational 
ability  for  initialization,  detail  processing,  or  control  break  processing. 
However,  he  can  make  CALLS  to  other  catalogued  system  or  user  defined  processes. 
The  user  can  create  temporary  items  for  operations  or  output.  When  processing 
coordinated  files,  the  user  can  specify  any  of  several  MISMATCH  options  based 
on  the  absence  of  either  the  control  or  slave  record.  The  options  are  to  by- 
pass the  mismatched  record,  abort  the  job,  or  process  the  record  using  a 
dummy  for  the  missing  record.  The  user  can  also  specify  the  maximum  number  of 
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records  to  be  searched  or  selected.  For  output,  default  column  headings  and 
editing  is  included  in  the  data  definition.  However,  Data  Analyzer  also  has 
extensive  report  definition  capabilities  which  the  user  can  use  to  override 
the  default  definitions.  There  can  be  table  look  up  for  output  value  editing 
Output  can  also  be  edited  for  decimal  point,  comma  insertion,  floating  $,  arid 
the  - or  CR  notation  for  negative  numbers. 


IC  YY/>LTHCh-*  ?4RANUaLL 

7 I TLF---“-“-*  * INTEHoGm  f iwii  uATL-aLi^lTlvt 


SERIAL  TITLE------'*  TnE  COHFOltp  jUUKnAi. 

SERIAL  M'MEP  — -*  !?*'« 

YEAH * 1 'if'* 

CATE * 1W*./11 

PAGES-- --«--* 


F ILtS» 


AUTHCR  N a n L - * HANUALl 
FIHST  NAI^E  — * F.  E • 


DESCRIPTOR — * DATE  SENSITIVE  F ILL 

DESCRIPT ICn-*  RdCOHDS  CHANGES  OYc.h  T i N L * N c T JUS  I SKrtPbRoI  OF  COuHtNT 
STATE 


DESCRIPTOR--*  PACKCP  U*TA 

DESCRIPTION-*  USED  To  nEEP  l)aTa  Kh  H«Sl  TIME  PERIOD^ 

DESCRIPTOR — * Tli-^E  ST«i.HlNb 

DESCRIPTION-*  ON  STCRt.1  l a I a 1 1 1 '■  a i'.  Pr.COHL'S  A nU  RE  P t a [ INC  GpUUPS  AN 
U USED  IN  SELECTION-  CHIT  EM  a.  uFEECTIVt  l/Alt-whEN  OPaNGE  OCCCHS 
IN  HtAL  IaORLU*  P.UT  »rfF.N  DAFA  cNTEntL 

DESCRIPTOR--*  SELECTION  CRITERIA 

DESCRIPT  ICN-*  PA  SEN-  ON  TInE  POIUlUT*  pFF'OrE*  aFIlp*  tvtR)  OH  PP.HIC'DI 
IN,  DURING*  UNTIL*  SINCE*  aLaMS) 


111 


■H 


ID  YYAUTHOR:  74RANDALL 

TITLE:  "Interrogating  Date-Sensitive  Files" 


Describes  the  unique  features  of  a date-sensitive  system  PRISM  (Personnel 
Record  Information  System  for  Management)  and  its  retrieval  system  PIRL  (PRISM 
Information  Retrieval  Language).  The  usual  way  systems  handle  time  is  to  keep 
a current  copy  of  the  database  and  take  periodic  snapshots  for  backup  and  re- 
covery. In  these  cases  the  date  relates  to  system  entry,  not  an  effective  date 
for  the  real  world  application.  This  type  of  historical  data  is  not  available 
to  the  user.  PRISM  solves  this  problem  by  also  time  stamping  the  effective 
date  in  terms  of  the  date  at  which  the  change  or  addition  becomes  effective 
for  the  application.  PRIL  then  allows  retrieval  using  these  time  qualifications. 

Data  definition  is  not  discussed  except  to  mention  that  there  are  two  types 
of  attributes  with  respect  to  changes  over  time.  Some  attributes,  such  as 
marital  status,  have  only  a single  current  value.  When  it  is  changed,  a new 
current  value  and  its  time  stamp  become  effective,  although  the  previous  value 
is  still  available  for  retrieval  with  this  system.  Other  attributes,  such  as 
skill  can  be  multivalued.  When  a person  acquires  a new  skill,  he  does  not 
necessarily  lose  his  old  skill.  However,  there  must  also  be  a way  to  replace 
or  delete  a multivalued  item  when  necessary. 

Selection  expressions  in  PIRL  include  the  usual  boolean  expressions  with 
respect  to  item  values  or  value  sets  (equal,  not  equal,  less  than,  less  than 
or  equal,  etc.).  In  addition,  there  are  time  qualifications  which  allow  spe- 
cification of  either  a point  in  time  (AT)  or  an  interval.  Intervals  can  be 
specified  so  that  selection  will  be  made  if  a condition  was  met  at  least  once 
during  the  period  (IN  a period,  BEFORE  a date,  AFTER  a date,  or  EVER).  Comple- 
mentary expressions  (DURING,  UNTIL,  SINCE,  and  ALWAYS)  require  that  the  condi- 
tion be  met  at  all  times  during  the  period.  Dates  of  occurrences  can  also  be 
pin-pointed  with  FIRST,  LAST,  NEXT,  PREVIOUS,  EARLIER,  and  LATER. 

Output  can  be  either  part  or  all  of  selected  records  or  statistical  tables. 
With  time  qualification,  formatting  the  tables  can  become  very  complex,  but  the 
article  doesn't  give  any  details  about  how  it  is  handled. 
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This  system  assumes  all  data  items  require  time  stamping  for  effective 
date,  but  it  should  be  a user  option.  Conceivably  there  are  four  types  of 
items  --  single  or  multi-valued  items  each  with  or  without  time  stamping.  Also 
there  is  a question  about  the  time  stamp  for  a group  of  items.  If  each  item 
had  a different  effective  date,  what  should  be  the  group  date.  Also  must  be 
able  to  handle  errors  which  should  have  no  effective  date.  Consider  an  erroneous 
value  that  is  entered  and  dated.  When  it  is  corrected,  no  query  should  probably 
find  the  incorrect  value  regardless  of  the  data  type. 
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Discusses  recovery  policy  in  a large  transaction  oriented  data  base.  Iden- 
tifies three  types  of  errors,  eight  procedures  which  allow  recovery  from  them, 
and  seven  actions  which  are  the  basis  of  the  various  procedures.  Some  actions 
are  event  triggered,  while  others  are  controlled  and  done  on  demand  or  on  a set 
schedule.  The  restart  and  recovery  policy  is:  (1)  the  set  of  procedures  for 

recovering  from  each  type  of  error,  (2)  the  set  of  actions  which  are  needed  for 
each  recovery  procedure;  and  (3)  the  frequency  of  the  controlled  actions. 

Errors  classified  by:  (1)  severity  — transient,  solid,  or  disaster;  (2) 

cause/origin  — hardware,  software,  or  user;  and  (3)  recovery  procedure  needed. 
Examples  of  errors  used  are:  (1)  data  base  crash  — loss  of  the  entire  data- 

base; (2)  user  errors  — incorrect  updates  entered  and  propogated;  (3)  core 
failure  — part  of  the  data  base  is  lost.  Sayani  states  that  the  relative 
frequencies  of  these  failures  are  1,  20,  and  5. 

Possible  recovery  procedures  for  each  error  type  are: 

A.  Data  base  crash:  (1)  copy  duplicate  data  base;  (2)  copy  last 

dump  and  reconstruct  using  after  images;  or  (3)  copy  last 
dump  and  reprocess; 

B.  User  error:  (4)  copy  last  dump  and  reconstruct  using  after 

images  up  to  the  error  transactions,  then  reprocess  them  and 
succeeding  transactions;  or  (5)  roll  back  the  data  base  until 
the  initial  error  and  reprocess; 

C.  Core  failure:  (6)  roll  back  data  base  until  last  checkpoint 

and  reprocess  transactions;  (7)  copy  last  dump  and  reconstruct 
using  after  images  until  last  complete  transaction  and  then 
reprocess;  or  (8)  copy  last  dump  and  reprocess. 
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Each  of  these  procedures  requires  that  certain  prior  actions  were  taken. 

The  following  actions  in  various  combinations  are  the  basis  of  all  the  re- 
covery procedures:  (1)  dump  the  data  base;  (2)  log  before  images;  (3)  log 

after  images;  (4)  log  transactions;  (5)  log  output  messages;  (6)  take  checkpoints, 
and  (7)  maintain  duplicate  database. 

Objective  of  restart  and  recovery  policy  (procedures,  actions,  and  fre- 
quency of  controlled  actions)  is  to  minimize  restart  and  recovery  cost. 
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Purpose  of  article  is  to  develop  a top  down,  structured  approach  (analogous 
to  structured  programming)  for  data  definition  and  manipulation.  Many  problems 
occur  because  languages  allow  user  (programmer)  to  define  any  data  structure  and 
perform  any  operations  on  them.  This  approach  defines  a set  of  data  structures 
(lists,  trees,  rings,  stacks,  queues,  and  dequeues)  and  the  set  of  meaningful 
operations  on  them  which  the  user  can  perform.  Structures  can  be  hierarchically 
nested  (e.g.,  a list  where  each  node  is  a queue  and  each  queue  element  is  a 
tree).  Proposed  DSDML  (Data  Structure  Description  and  Manipulation  Language) 
has  four  components:  (1)  definition  --  of  data  structure;  (2)  search  method  — 

access  paths;  (3)  manipulation  — set  of  legal  operations  on  each  structure 
(primitives);  and  (4)  extended  manipulation  --  frequently  used  sets  of  operations 
built  from  several  primitives. 

Article  focuses  on  data  structuring  for  storage  and  access.  Very  procedur- 
ally  oriented  aids  for  programming  user  in  navigating  through  and  operating  on 
data  structure.  The  non-programming  end  user  probably  doesn't  need  to  know 
most  of  the  details  covered.  However,  in  some  cases  this  structuring  could  be 
useful  to  the  end  user,  e.g.,  defining  a FIFO  or  LIFO  inventory.  Also  in  some 
cases  business  policy  defines  an  access  path,  e.g.,  ship  the  part  from  the  near- 
est warehouse.  Therefore,  from  a logical  perspective  the  user  may  want  some  of 
these  capabilities,  but  in  using  them  he  should  not  be  implying  the  correspond- 
ing storage  structure.  Also  a problem  occurs  if  too  many  restrictions  are 
placed  on  the  legal  operations  for  a structure.  If  the  legal  operations  for 
stacks  and  queues  only  allow  operations  at  the  ends,  how  do  you  correct  an 
erroneous  entry  in  the  middle? 


118 


IC  YY AUTHOR-*  74SK1NNE" 

TITLE  — -*  *A  HEURISTIC  APPROACH  TG  INDUCTIVE  INFERENCE  IN  FACT  HETR 

IEVAL  SYSTEMS* 

SERIAL  TITLE-—  — -*  CumhuNICaUChs  OF  Al> 

SERIAL  NUPbEH  — — * 17«1? 

PUBLISHER  — — — -*  AGN 

YEAR—— * 1S»7a 

DATE————  — * 1V7A/12 

■*  7 u 7 - 7 1 2 


PAGES' 


AUTHOR  NAMF-*  SKIN;mEH 
FIRST  NAME—*  C.  WILLIAM 


DESCRIPTOR  — * INFERENTIAL  RETRIEVAL 
DESCRIPTION-*  FCR  uEKIviNb  MCKfc  ln«N  STGHEu  FacTS 

DESCRIPTOR  — * QUERY  TYPES 

DESCRIPTOR  — * OLERY  RESPONSES 

DESCRIPTOR  — * ROLES  UF  INFERENCE 

DESCRIPTION-*  SIMILARITY  STRUCTURE*  LEVELS  OF  SIG^IF IUmnCE 
DESCRIPTOR--*  VALlUAllGN  ChIIERIm 

DESCRIPTICN-*  CAN  bE  USEu  TO  UF.TEOT  INCONSISTENCIES  wf'ERE  CEFlNEU  SIM 
1LARITY  STHUCIuKES  INDICATE  OTHERWISE 


ID  YYAUTHOR:  72SKINNER 

TITLE:  "A  Heuristic  Approach  to  Inductive  Inference  in  Fact  Retrieval 

Systems" 

Given  a query  of  the  form  "what  is  attribute  A for  entity  E,"  a "fact 
retrieval  system"  will  give  you  the  value  if  it  is  stored,  otherwise  it  will 
simply  tell  you  the  query  cannot  be  answered.  An  inferential  system  goes  a 
step  further  and  compares  the  entity  with  other  similar  entities  and  tries  to 
infer,  based  on  the  degree  of  similarity,  the  value  of  the  entity.  The  paper 
discusses  the  additions  needed  to  convert  a fact  system  into  an  inferential 
one.  In  addition  to  the  usual  database  information  the  system  also  needs  a 
similarity  structure,  defined  by  the  user,  which  allows  the  system  to  cluster 
similar  entities  in  terms  of  like  attributes.  User  must  specify  the  attributes 
on  which  to  consider  similarity  and  the  levels  of  significance  required  before 
two  entities  will  be  considered  similar  enough  on  which  to  base  an  inference. 
(Article  describes  the  actual  clustering  algorithm.)  Entities  are  more  similar 
if:  (1)  more  of  their  attributes  have  the  same  value;  and/or  (2)  those  attributes 

on  which  they  agree  have  a high  variance  among  entities. 

Four  types  of  queries:  (1)  Is  it  true  that  a given  entity  has  a given 
property  (attribute/value  pair)?  (2)  For  a given  entity,  what  attribute  has  a 
given  value?  (3)  What  entity  has  a given  property?  and  (4)  For  a given  entity, 
what  is  the  value  of  a given  attribute?  Three  types  of  responses:  (1)  the 

query  is  true  or  false;  (2)  the  entity  or  attribute  value  requested;  or  (3)  no 
response  (the  query  cannot  be  answered  with  the  available  data).  Inferential 
system  will  shift  more  responses  from  three  into  one  and  two.  However,  response 
types  one  and  two  should  be  qualified  by  their  reliability  or  confidence,  which 
is  provided  by  the  similarity  structure  (or  because  the  actual  value  is  in  the 
database  --  a fact  retrieval). 


Inference  useful  when  missing  data  or  inconsistent  data,  perhaps  from 
several  sources.  User  must  be  provided  with  a way  to  define  the  similarity 
structure,  levels  of  significance,  and  to  change  them.  Level  of  significance 
depends  on  the  user.  However,  unclear  whether  similarity  structure  should  be 
at  schema  or  subschema  level. 
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Seven  basic  data  base  objectives.  One  of  key  tasks  for  data  base  design 
is  to  determine  their  relative  importance. 

1.  Data  independence  --  to  allow  the  physical  restructuring  of  data 
while  not  affecting  the  application  programs.  The  logical  form 
of  the  data  and  access  paths  through  it  should  be  unaffected  by 
physical  changes. 

2.  Data  relatability  — system  should  automatically  maintain  data  base 
consistency  by  propogating  the  appropriate  changes  through  the  data. 
Applies  to  derived  items  and  inter-item  or  group  validation  criteria. 
Responsibility  for  this  function  split  between  application  program 
and  system.  Most  of  the  load  should  be  on  the  system  once  the  user 
has  defined  the  relationships  to  be  maintained. 

3.  Compatibility  — ease  of  conversion  between  different  hardware  and 
software  environments  when  a system  is  replaced  or  upgraded.  Also 
a problem  with  linkage  between  several  "independent"  DMS  being 
used  at  the  same  facility. 

4.  Structural  adaptability  — the  ability  of  the  system  to  restructure 
itself  in  response  to  changes  in  behavior.  To  know  when  to  change 
requires  performance  monitoring  and  user  specified  criteria.  To 

be  adaptable  and  able  to  change  requires  both  data  independence  and 
flexibility  and  generality  in  the  system. 

5.  Data  integrity  --  four  causes  of  errors  in  the  data  base  which  must 

be  monitored:  (1)  input  errors;  (2)  hardware  failures;  (3)  software 

bugs;  and  (4)  shared  access  (concurrent  updates,  deletes  by  one  user 
when  others  still  need  data,  and  deadlock).  Redundancy  required  for 
both  preventing  errors  (integrity)  and  correcting  them  (recovery). 

6.  Data  recovery  — two  basic  functions:  (1)  to  prevent  error  propo- 

gation  through  the  data  base  (requires  early  detection  either  auto- 
matically or  with  highly  visible  conditions  for  manual  intervention); 
and  (2)  to  repair  the  errors  that  have  occurred. 
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7.  Data  security  --  proposes  isolating  the  security  processes  in  a 

security  kernel.  With  greater  use  of  public  communications,  security 
measures  such  as  encryption  becoming  more  important.  Access  control 
must  allow  data  dependent  criteria  (instance  level  or  value  related 
criteria  as  opposed  to  schema  or  data  item  level  criteria). 

System  performance  must  be  monitored  for:  (1)  resource  allocation  (time, 

space,  and  volatility);  (2)  response  times  (for  queries  and  updates);  and  (3) 
other  user  specified  expectations  (such  as  ease  of  use,  currency,  accuracy). 
Finally,  trade-offs  must  be  made  between  the  basic  objectives  and  performance: 
(1)  data  independence  vs.  response  time;  (2)  redundancy  (for  integrity  and 
recovery)  vs.  storage  space;  (3)  security  checks  vs.  response  time;  (4) 
generality  and  adaptability  vs.  time  and  space;  and  (5)  volatility  and  re- 
organization vs.  efficiency  in  both  the  long  and  short  term. 

One  of  the  basic  design  tasks  is  to  determine  the  relative  importance  of 
the  seven  objectives  and  what  price  should  be  paid  in  terms  of  performance. 
These  are  user  decisions  and  a way  must  be  found  to  allow  him  to  make  these 
specifications  to  the  design  process  in  terms  that  are  meaningful  to  him. 
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74TAGGART 

"Developing  an  Organization's  Information  Inventory" 


Main  proposition  that  a data  item  is  inadequate  to  identify  information. 
Develops  the  concept  of  information  element,  which  includes:  (1)  the  attribute 

of  interest;  (2)  time;  and  (3)  the  entity.  Concept  evolved  from  four  areas: 

(1)  information  algebra  — more  than  a single  property  should  be  present  to 
identify  information;  (2)  Chapin  — any  attribute  can  be  the  focal  point  of 
interest  and  the  other  attributes  serve  as  identifiers;  (3)  Langefors  — four 
essential  components  — the  attribute  of  interest,  its  value,  the  time  for 
which  it  applies,  and  the  entity;  and  (4)  McDonough  — more  than  one  set  of 
attributes  may  be  needed  to  completely  identify  the  entity  of  interest. 


Fundamental  difference  in  state  and  event  attributes  based  on  how  they 
consider  time.  State  applies  to  a point  in  time.  Event  refers  to  the  change 
in  a state  over  a period  of  time. 

Information  element  characteristics  include:  (1)  entity  component  size 

(McDonough);  (2)  sequenced  entity  terms  — used  to  order  a set  of  entities; 

(3)  non-sequenced  entity  terms  — used  only  to  identify  not  order  entities;  and 

(4)  detail  versus  summary  information  elements  --  indicates  over  which  entity 
sets  the  summary  occurs  (if  five  attributes  are  required  to  completely  identify 
an  entity,  then  the  presence  of  only  four  implies  a summary  over  the  fifth 
attribute). 

Systems  such  as  ADS  and  TAG  have  problems  because  they  don't  allow  data 
items  to  be  grouped  into  user  relevant  information  elements  and  don't  adequately 
handle  time. 

Proposes  the  use  of  an  information  inventory  in  terms  of  information  ele- 
ments, in  addition  to  the  usual  data  dictionary.  Reports,  regardless  of  whether 
they  are  for  time  points  or  periods,  are  defined  as  collections  of  information 

I 

elements.  Suggests  three  uses  for  information  inventory:  (1)  identify  infor 

mation  duplication  in  reports;  (2)  determine  if  new  needs  can  be  met  by  infor 
nation  already  being  produced;  and  (3)  help  the  user  clarify  new  information 
requirements  (tries  to  help  the  user  who  has  a general  idea  of  what  he  wants, 
but  doesn't  know  specifically  what  to  ask  for). 
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TITLE:  "Developing  an  Organization's  Information  Inventory" 


Two  questions  raised  in  considering  article:  (1)  when  defining  his  problem 

should  the  user  define  his  information  requirements  in  terms  of  information 
elements  instead  of  or  in  addition  to  the  usual  data  items  and  groups;  and  (2) 
are  information  elements  an  appropriate  way  to  define  reports? 
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ID  YYAUTHOR:  75BURROUGHS 

TITLE:  "DMSII  Data  and  Structure  Definition  Language  (DASDL)  Reference 

Manual" 

DMSII  is  an  implementation  of  a variation  of  the  DBTG  specifications. 

DASDL  provides  the  Database  Administrator  with  the  facilities  to  completely 
specify  the  logical  and  physical  structure  of  the  database. 

Files  or  "data  sets"  can  be  organized  as  DIRECT,  RANDOM  (which  includes 
DBTG's  CALC  and  VIA),  RESTART  (special  system  database  used  for  recovery),  and 
INORDERED.  For  each  file  there  can  be  any  number  of  "sets"  or  pointer  arrays 
or  indexes  providing  access  paths  to  the  file.  Records  within  a file  are  defined 
by  name,  type,  size,  and  VERIFY  (specifying  a condition  to  be  tested  to  insure 
a record's  membership  in  the  file).  Data  item  definition  includes  name,  type 
(alphabet,  boolean,  and  signed  or  unsigned  integer  or  real),  size,  an  initial 
and  a null  value,  the  number  of  times  the  item  occurs  in  the  record  if  it  is 
repeating,  and  whether  or  not  the  item  is  required.  Items  can  be  grouped  into 
groups  by  specifying  the  item  names,  the  number  of  occurrences  and  whether  or 
not  the  item  is  required. 

For  RANDOM  files  DMSII  provides  five  types  of  linkages:  (1)  counted  — 

the  number  of  links  to  a record  is  maintained  and  the  record  can  only  be  deleted 
when  the  count  has  been  reduced  to  zero;  (2)  self-correcting  — when  the  record 
has  been  obtained  (through  its  disk  address  stored  in  the  "owner"  record)  the 
key  is  checked.  If  there  is  not  a match,  the  appropriate  index  or  set  is 
checked  to  find  the  proper  record  and  the  pointer  in  the  parent  is  corrected; 

(3)  symbolic  link  — the  linkage  is  through  a set  of  index  with  the  key  value 
rather  than  directly  with  the  disk  address;  (4)  unprotected  linkage  — the  disk 
address  pointer  in  the  "owner"  record  is  assumed  correct  and  no  checks  are 
made;  and  (5)  verified  link  — when  the  record  is  obtained  (through  a disk 
address)  a check  is  made  to  verify  that  there  is  agreement  on  the  particular 
key  item  value  (the  data  item  being  checked  does  not  have  to  be  a key  item). 
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TITLE:  "DMSII  Data  and  Structure  Definition  Language  (DASDL)  Reference 

Manual" 


Access  can  be  on  any  key  item,  which  can  be  specified  as  ascending  or 
descending,  whether  or  not  duplicates  are  allowed,  and  whether  inserts  should 
be  make  first  or  last  or  in  order  in  a data  set.  Access  can  be  indexed  se- 
quential, indexed  random,  through  ordered  or  unordered  lists,  or  with  a bit 
vector.  Since  most  of  the  links  are  through  disk  addresses,  there  are  several 
optional  checks  to  insure  that  the  records  obtained  are  the  ones  sought. 

I 

When  defining  the  database  it  can  be  specified  as  AUDIT  or  recoverable. 
Also,  synchronization  and  control  points  can  be  specified  for  roll  back  and 
recovery. 
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ID  YYAUTHOR:  75COMPUTER  ASSOCIATES 

TITLE:  EARL  - General  Information  Manual 


Earl  is  a report  writer  using  flat  files  with  extensive  defaults  which 
can  be  overridden. 

It  has  value  dependent  control  over  item  printing.  A tag  is  set  to  a 
value  by  an  if  statement.  The  value  of  this  tag  is  associated  with  an  item  in 
the  output  list.  Those  items  with  the  same  value  as  the  tag  are  printed.  Thus, 
the  same  item  can  be  printed  in  different  columns.  Several  values  of  the  tag 
can  be  concatenated  implying  a logical  OR  (print  item  if  tag  has  any  of  the 
values) . 

Defaults  are  item  names  for  column  titles,  input  format  for  output  format. 
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ID  YYAUTHOR:  75ESWARAN  + CHAMBERLIN 

TITLE:  "Functional  Specifications  of  a Subsystem  for  Data  Base  Integrity" 

There  are  four  subsystems  to  prevent  errors  in  a database:  (1)  security  -- 

prevents  unauthorized  access;  (2)  consistency  --  controls  concurrent  updates; 

(3)  reliability  — relates  to  hardware/software  failures;  and  (4)  integrity  — 
prevents  errors  due  to  lack  of  knowledge  or  careless. 

Integrity  is  based  on  a set  of  premise-action  statements  which  apply  to 
the  database.  They  are  a subset  of  those  premises  which  apply  in  the  real 
world,  but  are  limited  by  lack  of  knowledge  and  language  capacity  for  expres- 
sing them. 

An  integrity  subsystem  is  proposed  which  allows  for  the  definition  of 
premises  (or  assertions  of  correctness)  and  for  the  actions  when  the  inte- 
grity has  been  violated.  Definition  of  premises  are  separate  from  data  defini- 
tion and  are  in  a language  similar  to  the  query  language.  The  data  definition 
is  static,  but  premises  (assertions)  are  dynamic  and  user  can  change  them  (ig- 
nores effects  of  these  changes  on  database  integrity).  Needs  new  type  of  access 
authorization  to  modify  premises.  Proposes  a premise  catalog  (like  with  data 
definition)  to  answer  what  premises  are  in  effect  or  what  premises  apply  to  a 
particular  data  item.  May  be  desirable  to  allow  premises  to  attach  to  either 
schema  or  subschema  (let  user  be  more  restrictive). 


Classification  of  integrity  checks: 

t to  what  they  apply  --  entities  versus  sets  of  entities 
(tuple  vs  set) 

• how  they  apply  --  state  or  transitional  to  values  - with 
or  without  regard  to  past  value 

• when  they  apply  (or  are  enforced) 

immediate  --  always  enforced 
delayed  --  at  end  of  a transaction 
selectively  --  at  user  discretion 

• when  they  are  invoked  --  triggered  by  an  update  operation 

The  actions  when  a premise  fails  may  be  hard  (reject  the  transaction) 
or  soft  (make  the  change  but  issue  a warning). 
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Actions  on  a failure  of  an  assertion: 

• the  user  must  be  given  enough  information  to  "correct" 
the  problem 

• immediate  assertions 

return  assertion  violated  and  tuples  violating  assertion 
act i ons  skip  transaction,  change  request,  or  roll  back 

0 delayed  assertions 

return  error  code  (can’t  determine  which  tuples  caused  error) 
actions  must  back  out 

0 soft  assertions  — probable  errors  or  errors  which  are  allowed 
to  exist  but  with  proper  notification  to  users 

0 null  values 

treated  as  information  void 

shouldn't  cause  assertion  to  succeed  if  it  would  have 
failed  or  fail  if  it  would  have  succeeded 

J 

Set  of  compatible  items  may  be  defined  for  which  certain  operations  are 
allowed,  even  though  prior  conversion  may  be  necessary.  Examples,  arithmetic 
operations  allowed  between  integers  and  real  after  conversion,  but  not  between 
arithmetic  items  and  charcter  strings.  Extreme  example  would  be  dimensional 
analysis  of  arithmetic  operations. 
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"Exception  Handling:  Issues  and  a proposed  Notation 


This  paper  presents  a very  flexible  method  for  handling  exceptions.  Ex- 
ceptions are  conditions  that  are  brought  (rais1'  an  exception)  to  an  invoker's 
attention.  The  response  to  an  exception  1 handlinq  the  exception.  The 

notion  of  an  exception  is  very  important  i .nation  systems.  There  are  many 

reasons  why  a normal  path  of  processing  can  oe  interrupted.  The  user  needs  to 
specify  conditions  for  and  responses  to  exception  processing  situations. 
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Exceptions  can  be  raised  because  of: 

• range  failure  --  the  operation  cannot  satisfy  its  output  assertion 

• domain  failure  --  an  input  assertion  cannot  be  satisfied  by  a 

process 

• result  classification  --  provide  additional  information  about  the 

output 

• monitoring  --  notify  invoker  that  a condition  has  occurred 

In  the  above  exception  conditions,  the  invoker  should  be  allowed  to: 

1.  abort  the  operation  and  undo  its  effects 

2.  try  the  operation  again 

3.  terminate  operation  with  partial  results 

An  operation  (subroutine,  operator,  etc.)  can  cause  an  exception.  It  can 
be  raised  by  the  user  or  the  system.  Every  operation  should  declare  what  excep- 
tions it  can  raise.  Handlers  for  exceptions  can  be  declared  with  the  operation 
raising  the  exception  or  with  an  other  operation  within  the  scope  of  the  operation 
raising  the  exception. 

Three  ways  to  classify  exceptions  are  described  with  appropriate  responses. 
These  distinctions  allow  for  some  compile  time  checks. 

ESCAPE  --  requires  termination  of  operation 

NOTIFY  --  forbids  termination  of  operation 

SIGNAL  --  terminate  or  continue  operation 


Each  exception  handler  is  declared  to  be  one  of  the  above  types, 
same  terms  are  used  to  invoke  the  handler. 
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When  leaving  an  exception  handler,  the  last  statement  must  state  termina 
tion  or  continuation  of  the  operation  causing  the  exception.  This  must  be 
consistent  with  the  type  of  the  handler. 

EXIT  --  Terminate  the  operation  (ESCAPE  & SIGNAL) 

A valued  exit  will  send  back  a value  for  the  operation 
being  terminated 

RESUME  --  Resume  execution  after  the  operation  causing  the  exception 
A handler  has  the  ability  to  handle  other  exceptions  within  itself. 

I i 


ENDED  --  An  exception  raised  upon  normal  completion  of  an  operation 
An  ESCAPE  type  exception 

CLEANUP  --  An  exception  raised  when  an  operation  is  not  resumed 

Exceptions  can  have  default  handlers  which  are  systems  or  user  defined.  The 
user  should  have  the  ability  to  override  these  default  handlers.  By  declaring 
a handler  to  be  OPTIONS  a user  may  substitute  his  own  handler  for  it. 


A way  should  be  provided  to  get  back  to  the  default  handler.  RESUME 
i (DEFAULT)  will  invoke  the  default  handler. 

An  other  condition  called  DEFAULT  can  be  raised  in  a handler. 


A PASS  will 
An  exception  is 


pass  an  exception  condition  to  an  invoker  and  let  him  handle  it. 
propogated  upward. 


Notation  is  cumbersome  and  hard  to  understand. 
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TITLE:  "Semantic  Integrity  in  a Relational  Data  Base  System" 


Discusses  two  types  of  semantic  integrity  (state  and  transition),  require- 
ments for  the  subsystem,  and  the  components  of  domain  and  relational  constraints 
or  premises.  Although  written  from  a relational  perspective,  it  would  apply  to 
any  data  model. 

State  integrity  insures  valid  domain  and  relationships  for  items  and  sets. 
Transition  integrity  insures  that  only  valid  operations  done  on  values  and  sets. 
Transition  integrity  (related  to  abstract  data  types)  not  really  discussed. 

Validity  definition  (or  integrity  subsystem)  requires:  (1)  high  level, 

non-procedural  language;  (2)  processor  for  validity  (of  constraint)  expression 
language;  (3)  validity  enforcer  — to  decide  when  to  test  premise  and  to  actually 
test  it;  (4)  action  processor  --  to  specify  exception  process;  and  (5)  con- 
straint compatibility  tester.  Language  must  allow  definition  of  premise  and 
action.  Premise  must  specify  both  validation  criteria  and  when  it  applies  or 
should  be  tested.  Specification  of  when  allows  database  to  pass  through  tem- 
porarily invalid  states.  Premises  may  apply  to  either  item  domains  or  set 
membership  and  relationships.  Authors  state  separate  languages  required  for 
stating  domain  and  relation  premises,  but  the  reason  is  not  apparent. 
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LSL  is  a DBMS  offering  multiple  views  of  data.  By  using  a small  set  of 
primitives  a user  can  define  a view  and  the  constraints  which  apply  to  the 
view. 


The  basic  structures  are  record  type,  selector,  link,  and  expression.  Each 
has  a generation  statement  defining  how  to  create  it  and  an  intention  state- 
ment defining  constraints  on  the  structure. 


A record  type  is  a set  of  entities  composed  of  items  some  of  which  are 
candidate  keys.  Generation  defines  how  it  is  populated.  Intention  defines 
constraints  (value  check,  item  relationships)  or  validation  within  a record. 

A link  relates  two  record  types  --  defines  an  access  path.  Generation 
defines  how  link  is  created.  Intention  defines  mapping  (1  to  1,  N to  M). 

A selector  defines  a subset  of  a record  type  by  a boolean  selection  ex- 
pression. Generation  defines  those  entities  in  the  subset  and  intention  de- 
fines the  properties  of  the  entities. 

| An  expression  used  for  the  creation  of  access  paths  to  a subset  of  the  DB 

(between  many  record  types)  using  links  and  selectors. 


I 


Intentions  and  generations  for  links  and  selectors  are  under  user  (DBA) 
control.  He  can  create  them  when  needed  with  or  without  systems  maintenance 
(dynamically  when  needed  or  under  systems  control)  or  create  and  lock  out 
records  involved.  Links  are  created  bidirectionally  but  are  deleted  in  one 
direction. 

The  user  navigates  through  the  structure  using  a calculus-like  language 
which  operates  upon  groups  of  records  rather  than  one  record  at  a time. 

A relation  (hit  file)  is  the  result  of  a query.  It  is  created  by  using 
links  and  selectors  and  keeping  items. 
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LSL  Makes  a definite  distinction  between  defining  a structure  and  creating 
it. 

Missing  concepts:  if  an  intention  is  not  met  nothing  is  provided  to  handle 

the  exceptions.  No  definition  of  inter-record  constraints. 
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QLP  is  an  update/query  language  that  must  interface  to  DMS-1100  and  a 
database. 

QLP  has  operations  to  protect  the  database  against  inadvertant  changes.  A 
HOLD  freezes  the  database  and  makes  the  current  state  as  a hold  point.  All 
changes  to  the  database  are  temporary.  RELEASE  will  make  all  changes  permanent 
while  ROLLBACK  rolls  the  database  back  to  the  state  of  the  last  HOLD. 


The  selection  clause  has  an  in  or  out  of  range  check. 
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TITLE:  "Audit  Capabilities  of  Some  Database  Management  Systems" 

Basic  role  of  auditor  (both  internal  and  external)  is  to  validate  the  data 
and  its  interpretation.  Many  audit  packages  for  nondatabase  systems.  Database 
creates  problems  auditors  have  not  yet  resolved.  If  auditing  requests  are  made 
through  the  DMS,  then  it  is  not  a totally  independent  analysis.  If  auditing 
requests  do  not  go  through  DMS,  then  all  access  to  database  are  not  being  made 
and  controlled  through  DMS,  creating  a potential  threat  to  database  integrity. 
Three  possible  approaches  suggested  and  evaluated:  (1)  modify  existing  audit 

software;  (2)  establish  an  interface  between  current  packages  and  the  DMSs; 
or  (3)  design  audit  capability  into  the  DMSs.  Depending  on  the  methods  a 
DMS  uses  to  recover  the  database,  there  is  a similarity  in  the  data  required 
for  auditing  and  recovery. 

Paper  compares  a number  of  systems  (ASI-ST,  IDMS,  Data  Analyzer,  DYL-260, 
EASYTRIEVE,  GIM-II,  GIS,  IMS/90,  INQUIRE,  INSYTE,  MANAGE,  MARK  IV,  MARS  VI, 

Model  204,  OLIVER,  QUERY,  UPDATE,  RAMIS,  SYSTEM  2000,  and  TOTAL/SOCRATES)  on 
several  capabilities.  The  capabilities  include  data  definition  and  redefini- 
tion, data  structure,  ability  to  handle  synonyms,  validation  rules,  retrieval 
commands  for  selection,  sampling,  extracting,  file  and  entry  level  derivation, 
sorting,  and  report  definition  and  output  editing. 
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System  R is  a multi-user  relational  DBMS  developed  by  IBM  as  a research 
vehicle. 

The  SEQUEL  language  is  the  interface  to  the  database  for  both  the  pro- 
grammer and  non- programmer.  The  programmer  calls  SEQUEL  with  his  SEQUEL  com- 
mand as  a string.  Local  variables  can  be  included  in  this  text  and  can  be 
bound  to  their  local  addresses  (within  the  program). 

Access  paths  (for  performance)  between  relations  can  be  defined  as  images 
or  links.  An  image  is  an  index  which  can  be  declared  to  only  have  unique 
values.  A link  is  a physical  binary  link  between  tuples  (one  to  many)  based 
upon  a value  in  certain  fields.  Both  structures  can  have  a clustering  pro- 
perty where  tuples  with  common  values  are  physically  adjacent. 

A subschema  capability  called  the  VIEW  is  provided.  It  is  a definition 
of  a SEQUEL  statement  on  other  relations.  This  VIEW  can  be  used  in  a query 
or  update  (only  if  there  is  a 1 to  1 relationship  between  tuples  in  the  view 
and  tuples  in  the  underlying  relation). 

A transaction  is  a set  of  SEQUEL  commands  that  are  processed  as  one 
command.  The  user  may  specify  save  points  and  may  back  out  (undoing  all 
operations)  to  any  save  point. 

The  creator  of  an  object  (relation)  has  the  ability  to  control  the  object. 
He  can  grant  authorization  for  its  use  to  other  users  who  in  turn  can  grant 
their  authorizations.  These  authorities  include  read,  insert,  delete,  update, 
drop  (delete  a relation),  expand  (add  domains),  create  images  and  links, 
control  (define  views  and  triggers)  and  grant  (give  above  permissions  to  other 
users). 

Integrity  is  maintained  by  assertions  which  describe  permissible  states  of 
the  database  or  permissible  transitions  of  the  database.  Assertions  are  en- 
forced at  the  end  of  a transaction  or  the  user  can  explicitly  invoke  them.  If 
an  assertion  is  not  met  the  system  backs  out  the  transaction.  The  user  defines 
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that  an  assertion  be  invoked  upon  an  insertion,  deletion  or  update  of  a relation 
or  domain. 


A trigger  is  similar  to  an  assertion.  Instead  of  containing  a predicate 
it  contains  a sequence  of  SEQUEL  statements.  It  is  also  invoked  under  the  same 
conditions  plus  the  read  of  a tuple  or  domain. 


When  controlling  for  concurrency  System  R provides  three  levels  of  trans- 
action consistency: 

1.  least  isolation  from  other  users 

read  dirty  data  and  read  different  values  for 
same  item  during  transaction 

2.  access  clean  data  (data  not  being  updated) 
subsequent  access  may  give  different  results 

3.  access  clean  data  and  reads  are  reproducible  — 
logically  a single  user  system 


When  deadlock  is  detected  the  youngest  transaction  with  the  shortest  dur- 
ation locks  is  backed  out  to  the  last  save  point. 
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TITLE:  A Discipline  of  Programming 

Dijkstra  presents  two  control  structures  (guarded  statements)  which  are 
nondeterministic. 

IF^<guard> ->  <statement  list)  . . . FI 

A guard  is  a boolean  expression.  A guard  is  picked  at  random  and  evaluated 
until  a true  guard  is  found.  Then  the  statements  with  that  guard  are  performed. 

D0^<guard>  -»  cstatement  list»)  . . . OP 

Similar  to  the  IF  except  the  DO  is  repeatedly  executed  until  all  guards 
are  false. 
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This  paper  addresses  the  problem  of  granting  and  revoking  security  in  a 
multi-user  environment.  Authorization  is  discussed  in  terms  of  base  relations 
(tables)  and  virtual  relations  (views). 

The  creator  of  a table  can  grant  permission  to  use  this  table  to  others. 

The  following  operations  are  grantable: 

read  --  use  table  in  a query  and  define  views  upon  it 

insert  --  add  new  rows  to  a table 
» 

delete  --  remove  rows  from  a table 

update  --  modify  specific  columns  of  a table 

drop  --  delete  a table 

A creator  can  grant  any  of  them  or  ALL  or  ALL  BUT  certain  ones  to  any 
user,  or  can  make  them  all  PUBLIC.  Also  each  user  can  be  granted  permission 
to  grant  their  authorities  to  others.  Each  grantee  can  have  grantable  and 
nongrantable  privileges  from  one  or  several  sources  on  a single  table.  This 
leads  to  a network  of  granted  authorities. 

The  concept  behind  revoking  authority  is  to  go  to  a state  as  if  the  grantee 
never  received  the  privileges.  This  means  revoking  the  privileges  of  the  grantee 
and  to  all  others  granted  privileges  from  the  grantee. 

A grantee  can  receive  the  same  privileges  from  several  sources  or  can 
receive  the  same  privileges  from  one  of  his  grantees.  Two  methods  are  presented 
to  properly  revoke  privileges.  A grant  of  privileges  can  be  labeled  and  each 
subgrant  of  these  privileges  also  has  this  label.  By  following  the  label  through 
the  granting  process  the  proper  privileges  can  be  revoked.  Each  grant  is  time 
stamped.  In  the  case  where  a user  has  received  the  same  privileges  from  two 
different  sources  and  granted  them,  the  time  stamp  is  used  to  revoke  privileges 
properly. 
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Views  present  different  problems.  Certain  grantable  privileges  cannot  be 
performed  on  a view.  Authorizations  for  a views  creator  are  developed  by 
intersecting  the  authorizations  of  all  underlying  views  and  tables.  The  creator 
can  only  grant  those  authorizations  he  holds  for  all  underlying  tables  and  views. 

If  a view  is  dropped,  all  other  views  built  (wholly  or  partially)  upon  the 
dropped  view  must  be  removed  along  with  all  privileges. 


The  paper  does  not  address  the  following  problems: 

1.  SYSTEM  R has  no  provisions  for  a DBA.  Therefore,  no 
one  controls  the  grantor  with  respect  to  what  he  may 
grant  and  to  whom.  Only  a grantor  can  revoke  or  grant 
privileges. 

2.  A grantor  cannot  revoke  all  or  specific  privileges 
from  all  or  selected  users. 
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The  article  identifies  three  steps  in  database  design: 

1.  definition  of  information  requirements  for  the  design  process 

2.  consideration  of  the  information  requirements  for  the  per- 
spectives of: 

a.  information  structure 

b.  usage 

3.  integration  of  the  two  perspectives 

The  focus  is  on  the  information  structure  and  usage  perspectives.  From  the 
information  perspective  there  are  entities,  attributes  and  relations.  For  each 
entity  type  the  information  needed  includes  volume,  access,  performance  statis- 
tics, integrity  criteria,  and  access  controls.  For  attributes  or  data  items, 
the  information  Includes  length,  value  set,  average  and  maximum  number  of  occur- 
rences, probability  of  null  values  and  access  controls.  For  relations  (which 
may  be  one  to  one,  one  to  many,  or  many  to  many)  there  is  a need  to  know  the 
cardinality,  integrity  criteria,  access  control,  and  mapping  functions. 

From  the  usage  perspective  there  is  a need  to:  (1)  develop  a top  down 

identification  of  process  structure  and  process  data  interactions;  (2)  specify 
how  processes  use  data  in  terms  of  a limited  set  of  primitives;  and  (3)  pro- 
vide detailed  process  descriptions.  The  four  primitive  operations  identified 
are  FIND,  ADD,  DELETE,  and  MODIFY.  The  basic  command  format  is:  "OPERATOR 

(search  criteria,  ALL/UNIQUE,  output,  association,  statistics)."  These  primi- 
tives are  then  used  to  build  up  three  process  categories: 

1 . read  only  — FIND 

2.  modify  — FIND  and  MODIFY 

3.  size  changing  — ADD  or  DELETE 

For  each  process  information  requirements  include  precedence  ordering,  fre- 
quency of  use,  volume  of  data  processed,  and  timing  requirements  in  terms  of 
both  response  time  and  when  the  data  and  process  are  available.  According  to 
the  author,  PSL/PSA  provide  a way  of  expressing  and  documenting  the  requirements 
from  both  perspectives.  In  terms  of  the  actual  design  procedure  for  combining 
both  perspectives,  the  author  proposes  for  her  doctoral  dissertation  to  develop 
an  initial  design  from  the  information  perspective  and  modify  it  to  meet  the 
usage  requirements. 
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